Jakob’s original thinking is this is (I believe) correct. Permissions and users/groups are a ‘rat’s nest’, haha. I 100% agree on that.
It’s surprising it’s as far along as it already is.
The elephant in the room is the filesystem – especially for mobile. There is no standard filesystem across Android – there’s ext4, yaffs, Samsung’s RFS, etc. To implement ownership you’d need to have a rooted phone. Most ppl don’t have that.
Permissions might be the same on Linux whether you run ext3, ext4, xfs, zfs, etc , but not if you use ntfs, fat16, fat32, vfat, etc. So there’s no standard for filesystems between Unix flavors, Mac OS X, and Windows. Nor is there a standard API layer.
Well, unless you count FUSE, and I know everyone hates that , so… Plus I don’t think FUSE would be easy to get working on mobile.
I don’t know, how it is in go, but in cpp under linux one way would be to use stat() to get the uid of a file and then getpwuid() to get the username as a string. I think I used it once and it worked also for mac-systems.
To be clear, I’m not going to implement this. Someone else is welcome to of course, and it’ll be integrated if it’s not an unmaintainable mess and doesn’t seem to be a rabbit hole of future issues.
Note that any implementation will also need to take a serious look at the fact that this implies running as a user with elevated privileges and any risks that carries with it.
To participate to this discussion, without an authentication and authorization mechanism, syncthing is for personal usage and for exchanging documents with friends, family or small teams. I’ve looked a bit and found a couple of developments in go.
I’ve had just now an other idea!
Maybe easier than sync Permissions and owners would be the possibility to set in the folder-settings in syncthing the owner and permissions. So when you run syncthing as root, you can run it for different users on the same machine, without running severel instances of syncthing for different users. That would be much more efficient, specially on an ARM-Processor.
This option would be really cool
Running syncthing as root has quite serious security implications, as @calmh mentioned. It means that everyone who has access to the Syncthing REST API / web GUI (either because a password wasn’t set, or through carelessness / a 0day) can instruct Syncthing to read/write any file on the filesystem. Syncthing is effectively turned into a nice little rootkit.
For this reason, I doubt Syncthing will ever recommend users run it as root, or implement a feature which requires running Syncthing as root.
Remember that having several Syncthing instances means that each user can have their own configuration, which they can manage without affecting other users.
Its a QNap-NAS and there are for each user (family member) an account. So each user stores his data on the nas and cant see the datas from the other users. And they can embedd there “drive” into the filebrowser on windows, mac etc. So they can work on it as an local drive.
And the idea with syncthing is to sync the data also over the internet, when they are in the university ect.
That use-case sounds like you definitely want separate syncthing instances per-user, otherwise every user will sync all the data from all the users onto their own systems.
Assuming that the users will be able to elevate permissions on their own local machines, they will obviously be able to bypass any user / group permissions.
Sync file ownership most needed not for end users, but for system administrators in corporate area. For example, I need 2-side sync /home folder in about 20 computers, with about 50 users. All computers have same user/group list (using shared ldap user list), so all that I want is to keep uid/gid of files when I do sync.
Running about 50 clients from each user will eat all memory and cpu, this is bad solution.
So the good solution is run syncthing as root with sync uid/gid feature.
I understand that this will be some potential security breach with this mode, but if some hole will be found, it will work for single user instance too, so it must be fixed for all users, not only for root mode only.
Greatly respect all of the comments and concerns here… and some of the pitfalls.
Secondly, Syncthing is a great piece of technology, and compliments to all those who have made it a great success.
We have had similar problems as others, and have managed to come up with a solution for us.
‘syncthing-acl’ is a daemon that manages file permissions and ownerships across syncthing servers. We use it distribute our backups mainly, but originally it was developed for a resilient cloud based file-system.
We have used it for a while ( with … lets say improving success ), but it is alpha… I think it might help with some ideas/solutions. Its uses syncthing to propogate acl’s and ownerships.
BUT please be aware that this is work in progress.
I’m still struggling with ownership of files and directories. The Metadata of a file is as important as the content for me. Otherwise files belong to Peter would be accessible by somebody else in the case of a restore.
Maybe a suggestion about this topic: Would it be possible to implement this feature in a “sudo” way ?
I mean that if the ownership synchronisation feature is enabled then the golang code executes a kind of
sudo chown -R owner.group targetpath
GUI could display a warning on the ownership synchronisation feature saying that it requires sudo chown or runas permission on the target system. Or maybe that feature could also prevent from being activated if it fails to execute a testing command with sudo.
This way, no need to run synchting as root, just require a little tweak on the target operating system
