You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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)
The text was updated successfully, but these errors were encountered:
@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.
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:
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
in0750
) 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:In this example, the ACLs are used on what was a mode
0700
directory to additionally give RWX permissions on the directory to groupfiles
. However, any non-ACL-aware application will see the directory as if it simply had mode0770
.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
+x
bits set on specific files do matter to the user)The text was updated successfully, but these errors were encountered: