I want help you with development, but I am not a programmer, so I can help you only with ideas and bug-testing I hope that some others will post any patches for this feature…
I’d like to help, but i am not fimiliar with go. Is there a developer who wants to help us with this problem?
Great opportunity to get familiar.
No way man
There is no time to lern a new language. I hope an other developer will fix this problem. Pershaps in the next winter is enough time, to lern Go and add this feature.
Thanks for you work!
Any progress in this direction? It’s quite anoying with no ownersync permissions. I have all the time again problems, because some files have ownership “admin” and not “User1”, oder an other
So if this would be fixed, it would be great. I’m only a cpp-proger, no knowledge of goso far
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.
And for a Windows-system it’s done like explained here: https://msdn.microsoft.com/en-us/library/windows/desktop/aa446629(v=vs.85).aspx
I’ve researched a litle bit for golang:
Maybe you could implement it firstli for unix systems only? For other systems it will stay as it was until now.
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.
Hm, so there is no way around severel Syncthing instances on the same system?
Remember that having several Syncthing instances means that each user can have their own configuration, which they can manage without affecting other users.
Yes, thats thrue, but most NAS’s has weak performance and have already with one instance a lot to do.
Why do you have multiple system users on a NAS?
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.