In regard to the FUSE GitHub page, I have some questions:
Does the quote below mean SSHFS does support ACLs if
default_permissionsis not used?
Does it mean that if one needs ACL support and proper security, neither
allow_othershould be used as mount options? (It is very clear that
allow_othershould not be used without
If #2 is correct, does this mean that SSHFS mounts without
allow_otherwill correctly pass along the server's file-permissions and ACLs to the clients?
Source: GitHub - libfuse/libfuse: FUSE (Filesystem in Userspace) interface https://github.com/libfuse/libfuse
If you intend to use the allow_other mount options, be aware that FUSE has an unresolved security bug: if the default_permissions mount option is not used, the results of the first permission check performed by the file system for a directory entry will be re-used for subsequent accesses as long as the inode of the accessed entry is present in the kernel cache - even if the permissions have since changed, and even if the subsequent access is made by a different user. This is of little concern if the filesystem is accessible only to the mounting user (which has full access to the filesystem anyway), but becomes a security issue when other users are allowed to access the filesystem (since they can exploit this to perform operations on the filesystem that they do not actually have permissions for).
This bug needs to be fixed in the Linux kernel and has been known since 2006 but unfortunately no fix has been applied yet. If you depend on correct permission handling for FUSE file systems, the only workaround is to use default_permissions (which does not currently support ACLs), or to completely disable caching of directory entry attributes.
In my environment, all clients and servers run Linux and all use BTRFS (which supports ACLs). All GUIDs and UIDs match.