Syncthing Downloads from GitHub

Is there any reason why the etc folder is included in the Linux archives but not the Windows archives considering there is a Windows installer included there now?

EDIT: Sorry I mean Windows installer script

  1. That script creates a service running as LocalService, which it has been agreed is not a good idea, and exactly what an installer should actually do is still being debated. I only knocked it up very quickly because I wanted to install Syncthing as a service on a bunch of servers, and a day later lots of much better windows things started getting contributed.
  2. Getting the automated build process to build a Windows setup binary I think might take some effort, and they haven’t had their hands on contributed Windows setup scripts for very long.

I used to write C# apps for Windows running as LocalService / LocalSystem all the time … I don’t think there’s anything inherently wrong with that process. That’s usually better for something that’s a pure server - - like Windows NT or Windows Server etc.

The services I used to write in C# as LocalService / LocalSystem were not GUI-type apps… They were server apps that procesed files in one directory, archived them to SQL, and spit them out to another directory. Any UX/UI stuff came through a different GUI app which watched the SQL tables.

There’s really two minor issues, one major:

Minor: (1) Does the Windows service run for one user or all user?
(2) What sort of interface is provided to the user (UX/UI questions)? Given that there’s already a well-crafted REST API in Angular in the Go code, probably any standalone Windows GUI should probably just speak REST, even if it’s speaking rest to localhost on 8080.

Major:: (3) Automated build / automated installers are going to be really important. I know us developers want to see good documentaton and the ability to build any of the code from source… But users generally want to see a .zip/.exe/.msi file or a .deb or .rpm file , so they can just click and install the thing. Getting automated builds for everything (the Go code, the C# code, the GTK client) would be useful.

That the etc dir is not included in Windows builds is just historical. Should we include it now? Is the stuff in there useful for a random Windows user? It seems like it’s mostly for developers (and apparently controversial at that)?

See posts such as

The problem arises when running Syncthing as something privileged and not enabling authentication. The difference between Syncthing and any other services you may have been running as LocalSystem / LocalService is that Syncthing can be instructed to read/write any file it has permission to access by anyone who can open a connection on localhost:8080.

Oh, okay I see. Thanks for clearing that up – didn’t see those comments in the thread – but you are 100% right . Potential security hole for sure.

Hmm… Here’s the MSDN scoop on LocalSystem…

And the MSDN scoop on LocalService…

Seems like LocalService has way less in terms of privs. There’s also NetworkService to scope out.

But you guys are 100% right, that’s potentially a security hole. I guess it depends on what the implications of the following are (for LocalService) – these are the privs according to MSDN:

SE_CHANGE_NOTIFY_NAME (enabled) SE_CREATE_GLOBAL_NAME (enabled) SE_IMPERSONATE_NAME (enabled) Any privileges assigned to users and authenticated users

I don’t think LocalService has to run as Administrator. I think you can assign it to an arbitrary group. Often sysadmins add LocalService as Administrator 'cause it makes life easier to let your Service write to the filesystem, but can run with whatever privs you want to assign.

BUT – I see – if LocalService can read and write your shared files as a non-Admin, then that’s still a huge problem even if someone doesn’t gain access to Administrator on the box. The localhost:8080 web has no auth. So it’s a bit of a catch-22.

Good point though… Good luck guys, I’m sure you’ll figure this one out.

EDIT: Hang on… am I missing something, or is there a simple solution here? You guys probably already thought of this. Would something like the following solve the issue?..

Short Answer: Enable HTTPS and Password Authentication for GUI (including web services, the Angular web app, all of that).