Two suggestions for Syncthing, hopefully they are not too unrelated to pack into one thread:
Privilege drop. There are times when Syncthing is being run in an environment where support for running as another user isn’t readily available. Busybox builds. For example, I am running syncthing on a FreshTomato router. In cases like this, it would be great if Syncthing could be made to drop its root privileges. Perhaps a run-as user could be specified in the advanced configuration?
Turn off listening. My Syncthing network topography is essentially client-server. The central “server” listens on a static IP. All the “clients” just connect to it in a sort of virtual star. Some of those clients, as mentioned, are on routers and for safety I don’t want them to listen at all. Right now I set the listening address to loopback, but it would be nice if there was a setting to turn off Syncthing’s protocol listening entirely.
Dropping privileges is typically something programs do when they need those privileges for initial setup (e.g. listening on port 80) and then no longer. Syncthing doesn’t need privileges to start with so we recommend never running as root.
Typically, yes, but not solely. And in an environment without su, sudo, or runas then it would be a big help to be able to have Syncthing drop its privileges. Far safer than to have it run as root. And if it does it in the beginning, before it touches the network, then it’s pretty much just as safe as being run from the beginning as an unprivileged user.
This isn’t just me. This is many embedded or appliance computers. Think routers, NAS devices, and home security systems. These are often extremely cut down Linux systems. Sometimes just a kernel, busybox, and whatever embedded UI that appliance calls for. They oiften don’t have a lot of what you would consider the fundamentals of a posix system. Often no sudo, su, runas, or daemon commands.
Syncthing has been included in several package management projects for these types of embedded and appliance systems. This is because Syncthing is a great compliment to routers and NAS devices. I have it on my NetGear router that has the Tomato firmware on it. Many people who use Syncthing in that enviroment are just going to run it as root because there are sometimes no readily available better ways of doing it.
I do not see a significant issue with Syncthing dropping its privileges. There is superuser detection and warning code in there now, likely about as much code in the binary as dropping the privileges would take. Yes, it’s always better to run it as an unprivileged user from the get-go, but for people who have trouble getting the infrastructure in place for this, it would be very handy to have a failsafe. Keep the warning in place too. “Syncthing has detected it is being run as root. This is dangerous - Syncthing has therefore dropped its root priviliges, but it is still better to run it as an unprivileged user.”
There’s also a technical issue that due to limitations with the Go threading model it’s not actually possible to change user reliably from inside a Go program.
But regardless I also don’t think we should duplicate normal OS functionality to enable running on systems with an incomplete OS. That way lies madness.
why syncthing should solve problems that you’ve induced on yourself
don’t think we should duplicate normal OS functionality to enable running on systems with an incomplete OS. That way lies madness.
Sure, it’s madness… MADNESS to want to run Syncthing on a linux-based NAS. How crazy to have whole directories on your home LAN’s network storage solution automagically and securely synchronize with other devices. </sarcasm>
Treating it as though I’m trying to pawn off personal problems on you is dismissive of a usage case that, if you take a step back, I think you’d admit is pretty compelling. It’s not MY problem, it’s just A problem. You wrote the software, but it’s the people who use it that define the usage cases. It’s not the cases which you (you personally) think of when you write it that make software great, but the ones you didn’t think of when you wrote it that it ends up being perfect for.
TBH, Syncthing is such a great fit for this environment, I’m surprised you didn’t think of it. Syncthing is, otherwise, just perfect for embedded platforms. It seems that you have reduced its reliance on the OS on purpose. It is statically linked, can automatically upgrade, doesn’t use syslog or any other system-based logging resources (leaving that up to the invoker to sort out), and its built-in web UI requires nothing from the system it is on. It is already divorced from almost all OS support requirements, obviously by design. That’s a really great design and it makes it eminently suitable for embedded devices. It already detects when being run as root, and the time it would take to implement this change is less than than the time taken to discuss it.
There’s also a technical issue that due to limitations with the Go threading model
I would be happy to make the changes and submit the patch.
Anyway, enough said. I’ve made my case. If you’re still against it, it’s your software to decide the direction of. I don’t have the time or inclination to fork() it (hah, get it) nor is this issue important enough to warrant that.
I personally would be against this, as I still disagree with this being a problem.
It’s the first case this has ever come up in the 7 or so years of syncthings existence, and you seem to be the only one needing this, so I think it is a problem specific to you, and this would end up being a feature that has a sole user, you. Yet the code behind it would have to be forever maintained by us.
Sure, syncthing is statically compiled and what not, but that mostly comes from the language, that also doesn’t give a good reason to start duplicating OS functionality.
I don’t see any good reason to have it, other than “my os doesn’t come with sudo”, which is clearly THE problem.
If getting sudo available on your OS is more work than maintaining a fork of syncthing, then probably that’s the sensible direction to go, I suspect the patch would be small and wouldn’t need merge conflicts resolving often.
Also, not having this doesn’t suddenly prevent you from running syncthing. Sure, it’s suboptimal but same way like file watching being flaky on freebsd is suboptimal.
Everyone has to live with the quirks of their platform, and in this case the quirks are in the OS, rather than syncthing.
Even if some strong words were used, nobody is dismissing use-cases. I don’t see anyone saying that you shouldn’t drop privileges. Just that it shouldn’t be Syncthing that does it. And on that note:
If on this limited system, Syncthing can drop its privileges, shouldn’t the same mechanism be able to drop privileges before running any program? I am imagining that this would be some trickery in the monitor before calling exec.Command. Then create a program e.g. called drop-privileges, that does the same thing and instead of running Syncthing, run whatever command is given to drop-privileges. That way not every program not needing privileges needs to implement and maintain their own mechanism.
Well apart from the reason already given (none of “you” ever ran such a system) a second reason why this hasn’t come up yet is the above: If I encountered this problem, I wouldn’t have asked myself “can syncthing drop privileges” but “how can I drop privileges on this platform”. And if there’s no way, can I create something that drops privileges before executing a command. And if I think this is important to Syncthing, I’d advertise it here in a user story and/or add it to https://docs.syncthing.net/users/contrib.html.