Em relação à página do FUSE GitHub, tenho algumas perguntas:
A citação abaixo significa que o SSHFS oferece suporte às ACLs se default_permissions for não usado ?
Isso significa que, se alguém precisar de suporte ACL e segurança adequada, nem default_permissions nem allow_other devem ser usados como opções de montagem? (É muito claro que allow_other não deve ser usado sem default_permissions .)
Se o número 2 estiver correto, isso significa que o SSHFS é montado sem default_permissions e sem allow_other transmitirá corretamente as permissões de arquivo do servidor e as ACLs para os clientes?
Fonte: GitHub - libfuse / libfuse: interface FUSE (Filesystem in Userspace) link
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.
No meu ambiente, todos os clientes e servidores executam o Linux e todos usam o BTRFS (que suporta ACL's). Todas as combinações de GUID e UID.
Tags permissions security sshfs acl