I’ve just been checking that forum post out, looks very good not too sure on the name but I do agree from the screenshots I’ve seen, it is what Syncthing should be shipped as for all OSes not just Windows but this is a start.
@AudriusButkevicius@calmh do you still want me to update that repo or would you rather have talks with @canton7 to see if it can be renamed to simply “Syncthing” and made part of the automated builds?
I guess if @canton7 adds service control, his thing becomes superior to nssm + SyncthingTray?
In which case perhaps we should offer that as the default thing for Windows.
Heh, they say the 2 hardest problems in computer science are cache invalidation, naming things, and off-by-one errors. Naming things is the bit I suck most at. You can tell it was never meant to become “official” anyway! I’m happy to re-brand if the community deems that the most sensible approach, but I have reservations about using the ‘Syncthing’ name: that would cause undue confusion. Saying “Syncthing is a windows host for Syncthing” in a clear way is not something I want to attempt!
I’ve replied to your post in the SyncTrayzor thread:
Thanks for making an installer. It worked perfectly on Windows 7 64 bit, Server 2012 R2 & Server Essentials 2012 R2.
Assuming it evolves from here (once service vs start on login is hammered out), one thing that is needed is to add the TCP port 22000 Windows firewall exception automatically.
Good point. Using a tray icon causes windows to (by default) prompt for a firewall exemption, at least on my home machines. Once you start getting into group policy, and services, etc, that’s going to become a trickier topic.
Well done . This project is really picking up some developer momentum. That’s really awesome to see.
I’d be happy to load up some EC2 instances and test it there. I’ll be able to test on Windows Server 2003 R2, 2008, 2008 R2, 2012, and 2012 R2.
Just let me know if there’s any formal acceptance criteria, or any requests for what OS it needs to be tested on. I have ISOs for every version of Windows going back to like Windows ME… I can load em up pretty quick in EC2 or VMware.
SyncTrayzor and Syncthing-GTK are linked from the Syncthing home page. They’re both mature, stable downloads with large numbers of users. I’m not sure I’d call them DIY…
Edit: @Curtis_Newton completely reworded the post I responded to, so this is no longer relevant.
Most services do not need such a high privilege level. If your service does not need these privileges, and it is not an interactive service, consider using the LocalService account or the NetworkService account. For more information, see Service Security and Access Rights.
Syncthing can run perfectly fine under the LocalService account (NT AUTHORITY\LOCAL SERVICE) which is much better suited to it. It’s profile folder will be placed under C:\Windows\ServiceProfiles\LocalService\AppData\Local\Syncthing\ and will not be accessible by non-elevated accounts, which enhances the security of the private keys present in the profile folder. I’m running it this way myself, also with NSSM, and it works fine.
The problem is slightly more complex, and stems from two facts:
Syncthing needs to be able to read and write the files it is synchronizing.
By default, Syncthing can be configured by any user on the local machine.
These mean that, by default, any user on the local machine has access to any file which the user running Syncthing has access to.
If Syncthing is running as SYSTEM, then any user on the machine (including malware which hasn’t yet got administrative rights) can access virtually any file on the filesystem. That’s basically a rootkit. This is bad.
If Syncthing is running as LOCAL SERVICE, then by default it won’t have access to any files. Giving it access to files gives access to any process running as LOCAL SERVICE. This is bad. LOCAL SERVICE is meant to be a very restricted account.
Also remember that files created by Syncthing will be owned by the user Syncthing is running as. Having your files owned by a system or service account may or may not cause issues for you.
The only sensible thing to do when running Syncthing as a service is to run it as the user whose files you want to synchronize. This obviously makes the setup process a bit more complex, and makes multi-user setup a bit harder.
At the end of the day, starting Syncthing on login is a much more safe and user-friendly approach, particularly for new users. This is what all the major wrappers do.
All of this is explained in the docs, and there’s also this thread which is linked just a little further up in this thread.
(Setting a GUI password mitigates some of the issues listed above to a degree. However, 1) You’re now relying on there being no undiscovered vulnerabilities in Syncthing, 2) This isn’t particularly newbie-friendly, and 3) I saw no mention of the very pressing need to do this in @maxwelleite’s project instructions).
I agree with almost everything you say there, but in my case I want to run it as a service, not on my laptop but on a home-server, but not under an elevated account. I don’t access those files directly so the folders that are being synced cannot even be accessed by any user account of the system, only LocalService and of course an admin account. Since I’m the user myself and nobody else, I don’t need user-friendly. I don’t have anything but Windows services and Syncthing running under Local Service so it should be fine this way.
I disagree with the point you make about every process that runs under the LocalService account having access to all files you gave LocalService access to being a security risk. If Syncthing runs under a user account, all processes running under the user account have access to those files as well, than that would be a security risk too. A user account that starts Syncthing upon logon starts 70 other processes as well, each of which is a potential attack vector, plus there is a potentially dumb user controlling all of them and opening them up to phishing attacks etc. That’s a security risk too, especially for those synced files I’m trying to protect. The LocalService account starts Syncthing and some unavoidable Windows services and that’s it.
Anyway, the point I’m trying to make is not that I endorse running as a service for most users. It’s that an installer which explicitly installs Syncthing as a service should at least not default to the SYSTEM acccount. If a user of this installer cannot handle the hassle of correctly setting up folder permissions for the service (running under a separate user account or the LocalService account), they shouldn’t run as a service to begin with, in my opinion.
That’s fine. It’s a valid use-case. My point is more that people who have that use-case tend to know the risks and trade-offs, and also don’t use installers that other people have made. My post was a criticism of @maxwelleite’s installer’s approach.
I think you mis-read me. I said that starting as SYSTEM was bad, because SYSTEM has access to one hell of a lot of stuff, and giving all local users read/write/exec use of the SYSTEM account is a Very, Very Bad Thing. I said that using LocalService was bad because you need to expand the rights of LocalService to allow it to read/write the user’s files: this expands the privileges of all processes running as LocalService, and is also a manual step which your newbie who’s running @maxwelleite’s installer needs to guess.
The user’s files are one risk. The user’s entire system is quite another. Allowing a dumb user to give a malicious process access to their files is an accepted risk. Allowing a dumb user to give a malicious process administrative access to everything (through the SYSTEM account) has much more severe consequences.
Agreed, apart from I’d say that an installer should not default to any account - there’s no sensible account to default to which won’t either cause confusion for new users or give the user a loaded footgun.
All of this has been discussed to death in the past, and I’m parroting old agreed-upon points for the benefit of @maxwelleite, who appears not to have read the threads he advertised his installer on. The official approach is that Syncthing should be run as the user whose files it’s synchronizing. If people want to violate this, they’re on their own and it’s their responsibility to understand the risks and to keep themselves safe. People who recommend that new users do not follow the official approach (or by extension provide installers which do not follow the official approach) should reconsider.
Hence why this is no longer updated. I’d recommend you move over to SyncTrayzor and for anyone else that doesn’t wish to follow this method, do it your own way but remember what you’re opening up.
I’m happy to re-brand if the community deems that the most sensible approach, but I have reservations about using the ‘Syncthing’ name: that would cause undue confusion. Saying “Syncthing is a windows host for Syncthing” in a clear way is not something I want to attempt!