Multi user fileserver

General
1

Hello. This is my first post on this forum, so please my gentle if this has been answered/considered before. I have searched though and did not find similar.

I would like to Syncthing-enable my file server. I have partially done that now, by having systemd spawning a Syncthing daemon for each user. But security wise that sucks: Any user able to logon to this server is able to access any local Syncthing port.

So I was thinking about the possibility to setup a webproxy, with SSL and some kind of authentication. Based on the login the proxy should connect to the Syncthing instance that user is authorized to use. This would also enable the user to securely remote control his personal server instance.

Am I looking down the wrong path here, has anything similar been done, or do anybody have other suggestion on how to solve this.

Thanks

2

From the top of my head it sounds like you may need to build a custom control panel thing that replicates (part of) the Syncthing GUI, while properly authenticating the user and speaking to their specific Syncthing backend.

Another option would be some sort of proxy that authenticates the user and then transparently proxies the connection to the right Syncthing while adding an X-API-Key header. You’d need to know the correct API key, preferably by setting it yourself in the environment before starting Syncthing.

3

Thanks for your thoughts. I am mostly sysadmin and not much of a programmer so I would prefer the later suggestion. That was also what I had in mind when I wrote the above. I have setup nginx proxies before, but not pointing to a dynamic target. I will have to dig into how that can be achieved.

As for which Syncthing instance to connect to, I would think that detecting the userID for the syncthing instance might give sufficient information on a Linux server:

In bash something like this:

SPID=$(ps -u $USER | grep syncthing | cut -f1 -d" "); lsof -p $SPID -a -iTCP -sTCP:LISTEN | grep localhost

(just toughs - dont use: error prone) I think a more reliable way to find the port number must be possible.

4

Wow, that’s exactly what I have been looking for as well! On Unix/Linux, inter-process communication (IPC) between multiple users that should not go via 127.0.0.1 is normally done using local UNIX domain sockets, am I right? So every syncthing instance should have to tell the webserver process daemon, that handles the authentication, via a UNIX domain socket locally; which port and API key should be used (or, for even better security, use hashed and salted passwords/keys - this way, neither the webserver daemon nor the syncthing instances have to save the plain password/API key). If the user from the internet puts in the right username + password, he/she gets redirected to the right syncthing instance after authentication (by giving him/her the right API key). Could such a UNIX domain socket functionality be implemented into Syncthing? The webserver daemon process takes the server role, while the syncthing instances take the client role. The RESTful API can still be done using 127.0.0.1, but the authentication via UNIX socket. Please correct me for errors!

5

I’m sure something unix-sockety could be rigged up, but not sure how it ties into your scenario really. There is a ticket for listening on a unix socket on Github, should be fairly easily locatable.

2 Likes