Switch to running as a user service instead of a system service
legowerewolf opened this issue · 8 comments
See #9 for more discussion of user services.
Just to get it right, that would entail not needing to disable the read-only state for the general system, right?
As the script exists currently, you don't need to break the readonly seal. But yes, as a user service, you shouldn't need to break the readonly seal.
As the script exists currently, you don't need to break the readonly seal. But yes, as a user service, you shouldn't need to break the readonly seal.
Wait, if it isn't needed either way, where does all this talk about the read-only mode come from in the context of Tailscale on the Steam Deck? (and even this repo's readme)
Installing this doesn't require users to break the readonly seal, but if users want to do other things on the root FS, using a different method than we're using (system extensions + the default overlay FS), our install method can cause conflicts with that.
Switching to a user service, installing only in the user's homedir, means we don't cause issues for those people.
Thank you for taking the time to explain. :)
I've done some experimenting and research. TLDR: It doesn't look like user services can do this.
- I put the tailscale/d bins in my homedir and copied the unit file into the user units dir. After tweaking to get it to find the bins in their new place, all I got was permission issues. A ton of "permission denied."
- "For user services of any other user [than root], switching user identity is not permitted." So running a user service as the root user isn't an option.
I think for now the best thing is to keep this as a system service that uses an extension for putting binaries in the right place. Ideally we could set the extension dir to overlay below /usr but I don't see that as an option yet.
CC @gustakasn0v, @bertogg
Tailscale is looking for access to /usr/bin/iptables and /dev/net/tun. You can run it in user space with the flag --tun=userspace-networking but it will no longer have the iptable routes or the interface. This means incoming connections will work, but outgoing connections must be setup with a proxy. It can be set up to host a SOCK5 or HTTP proxy locally.
To demonstrate this, say we have two computers with the following ips 100.0.0.1 (where tailscale is) and 100.0.0.2 (the peer). If we run tailscaled with the following flags --socks5-server=localhost:1055 --tun=userspace-networking this will work:
100.0.0.1 $ nc -lnv 0.0.0.0 9000
100.0.0.2 $ nc 100.0.0.1 9000
But this will not
100.0.0.2 $ nc -lnv 0.0.0.0 9000
100.0.0.1 $ nc 100.0.0.2 9000
Instead it will need to be changed to this to use the SOCK5 proxy for outgoing connections:
100.0.0.2 $ nc -lnv 0.0.0.0 9000
100.0.0.1 $ nc -X 5 -x 127.0.0.1:1055 100.0.0.2 9000
Hm. Knowing that TS wants those paths, it might be possible to allow it without needing userspace networking. Thanks for the data!