Support workflows making use of POSIX ACLs

[intelfx]

Feature description

This is not a feature request about specifically supporting syncing POSIX ACLs, but rather about supporting workflows that involve POSIX ACLs.

It would be nice if Syncthing did all or any of the below:

• support limited modes of syncing permissions (e. g. x-bit only or umask only) that would have less affinity to break ACLs than existing full permission sync mode
• detect files that have POSIX ACLs set and extract/set actual group permission bits
• fully support syncing POSIX ACLs (with or without mapping, in particular a "sync only generic ACLs" mode would likely be useful, or "map ACLs of the root directory owner")

Problem or use case

The root of the problem is that POSIX ACLs are arguably mis-designed in one specific way: they repurpose normal UNIX group permissions (i. e. 5 in 0750) to mean the "ACL mask permissions", which is a value that is implicitly ANDed with all ACL entries. The UNIX group permissions are, instead, converted into an ACL entry. For instance:

$ ls -ld ~
drwxrwx---+ 1 intelfx intelfx 2.0K Mar 17 07:22 /home/intelfx

$ getfacl ~
getfacl: Removing leading '/' from absolute path names
# file: home/intelfx
# owner: intelfx
# group: intelfx
user::rwx
group::---
group:files:rwx
mask::rwx
other::---

In this example, the ACLs are used on what was a mode 0700 directory to additionally give RWX permissions on the directory to group files. However, any non-ACL-aware application will see the directory as if it simply had mode 0770.

Thus, if Syncthing is used to sync such a directory onto another host, Syncthing on that host will create the directory as mode 0770, which is incorrect (and might even be a security problem).

Alternatives or workarounds

• not using ACLs
• not using permission bits sync (which is unusable if we are syncing, say, a source + build tree, where +x bits set on specific files do matter to the user)

[calmh]

Thorny stuff.

[intelfx]

@calmh While I would be delighted if Syncthing suddenly grew comprehensive support for ACLs, the most labor-effective improvement that could be done is IMO simply to make Syncthing ACL-aware: that is, instead of stat()+chmod() use libacl (or equivalent) to get/set file permissions — but only care about those ACL entries that map directly to UNIX permission bits.

[cluck]

This "weird" repurposing of group permission bits in POSIX ACLs is actually a backward compatibility feature designed to keep both ACL-aware and ACL-ignorant software on the same page regarding access permissions and to fail back onto "safe" behavior when a 1:1 mapping is not given.

The fundamental trick is to switch the owner group to an overly restricted owner group with permission/mask rwx, and "open up" with potentially less wide permission bits to more independent groups via group ACLs. That way, ACL-ignorant software will deny access to groups enabled via ACL, and "pass down" removed permissions on the overly restricted group to all ACL based groups, without knowing they exist.

Translating to syncthing this means that the chosen restricted owner group should be preserved/replicated.

I don't know what syncthing does. By default, under POSIX, when a process creates a file or directory, the primary group the process is runnung as, will also become the owner group of the file. This can be overruled when the containing directory has the Set Group ID (a.k.a. setgid, SGID) set, in which case the owner group of that directory is inherited to the newly created file/directory.

This last part is probably what syncthing should support.

To add this SGID bit to an existing directory tree, all sub-directories (but not the files) need to be updated. On Linux this can be done with find /share -type d -exec chmod g+s {} \;. Similar settings can be accomplished with tweaking ACLs on native Windows.

I'm unsure if syncthing overrides these default ownerships after creating the files.