starred/s3fs-fuse

Fork 0

mirror of https://github.com/s3fs-fuse/s3fs-fuse.git synced 2026-04-25 13:26:00 +03:00

[GH-ISSUE #775] ACL doesn't fully work? #442

New issue

Closed

opened 2026-03-04 01:45:37 +03:00 by kerem · 5 comments

kerem commented

2026-03-04 01:45:37 +03:00

Owner

Originally created by @mateusz- on GitHub (Jun 7, 2018).
Original GitHub issue: https://github.com/s3fs-fuse/s3fs-fuse/issues/775

Version of s3fs being used (s3fs --version)

1.82

Version of fuse being used (pkg-config --modversion fuse)

2.9.4

System information (uname -r)

4.14.42-52.37.amzn1.x86_64

Distro (cat /etc/issue)

Amazon Linux AMI release 2018.03

/etc/fstab entry (if applicable):

btr-ftp     /ftp        fuse.s3fs _netdev,allow_other,use_xattr 0 0

Details about issue

Below, I created a new dir in my home directory, set default ACL permissions for that dir, and then created a new file in that dir. Lastly, I verified ACL on that new file.

I then proceeded to do the same in the /ftp directory, which is a s3fs mount. The result is not the same.

$ mkdir foo
$ setfacl -d -m g:btrst:rwx foo
$ touch foo/bar
$ getfacl foo/bar 
# file: foo/bar
# owner: ec2-user
# group: ec2-user
user::rw-
group::rwx      #effective:rw-
group:btrst:rwx     #effective:rw-
mask::rw-
other::r--
$ mkdir /ftp/foo
$ setfacl -d -m g:btrst:rwx /ftp/foo
$ touch /ftp/foo/bar
$ getfacl /ftp/foo/bar
getfacl: Removing leading '/' from absolute path names
# file: ftp/foo/bar
# owner: ec2-user
# group: ec2-user
user::rw-
group::rw-
other::r--
$ getfacl /ftp/foo/
getfacl: Removing leading '/' from absolute path names
# file: ftp/foo/
# owner: ec2-user
# group: ec2-user
user::rwx
group::rwx
other::r-x
default:user::rwx
default:group::rwx
default:group:btrst:rwx
default:mask::rwx
default:other::r-x

Originally created by @mateusz- on GitHub (Jun 7, 2018). Original GitHub issue: https://github.com/s3fs-fuse/s3fs-fuse/issues/775 #### Version of s3fs being used (s3fs --version) 1.82 #### Version of fuse being used (pkg-config --modversion fuse) 2.9.4 #### System information (uname -r) 4.14.42-52.37.amzn1.x86_64 #### Distro (cat /etc/issue) Amazon Linux AMI release 2018.03 #### /etc/fstab entry (if applicable): ``` btr-ftp /ftp fuse.s3fs _netdev,allow_other,use_xattr 0 0 ``` ### Details about issue Below, I created a new dir in my home directory, set default ACL permissions for that dir, and then created a new file in that dir. Lastly, I verified ACL on that new file. I then proceeded to do the same in the /ftp directory, which is a s3fs mount. The result is not the same. ```sh $ mkdir foo $ setfacl -d -m g:btrst:rwx foo $ touch foo/bar $ getfacl foo/bar # file: foo/bar # owner: ec2-user # group: ec2-user user::rw- group::rwx #effective:rw- group:btrst:rwx #effective:rw- mask::rw- other::r-- $ mkdir /ftp/foo $ setfacl -d -m g:btrst:rwx /ftp/foo $ touch /ftp/foo/bar $ getfacl /ftp/foo/bar getfacl: Removing leading '/' from absolute path names # file: ftp/foo/bar # owner: ec2-user # group: ec2-user user::rw- group::rw- other::r-- $ getfacl /ftp/foo/ getfacl: Removing leading '/' from absolute path names # file: ftp/foo/ # owner: ec2-user # group: ec2-user user::rwx group::rwx other::r-x default:user::rwx default:group::rwx default:group:btrst:rwx default:mask::rwx default:other::r-x ```

kerem closed this issue

2026-03-04 01:45:37 +03:00

kerem commented

2026-03-04 01:45:38 +03:00

Author

Owner

@tam116 commented on GitHub (Apr 15, 2021):

Seeing the same thing, also sticky bit doesn't seem to work either

@tam116 commented on GitHub (Apr 15, 2021): Seeing the same thing, also sticky bit doesn't seem to work either

kerem commented

2026-03-04 01:45:38 +03:00

Author

Owner

@gaul commented on GitHub (Apr 25, 2021):

Related to #844 and #1517.

@gaul commented on GitHub (Apr 25, 2021): Related to #844 and #1517.

kerem commented

2026-03-04 01:45:38 +03:00

Author

Owner

@michaelsmoody commented on GitHub (Sep 16, 2022):

This is one of an unfortunate number of blocking issues that is stopping me from using S3FS in a production implementation and has, well, (and I really hate to say this, because it sounds....unforgiving) caused a waste of around 3 days of work chasing various bugs and problems. I'll be opening bug reports about them, but, this one is a deeply blocking issue (POSIX compatibility being a complete necessity).

Long story short, we've setup an Amazon Linux 2 3 system cluster running S3FS against an S3 bucket. All of which is in GovCloud (that was a minor adventure as well). The systems are in FIPS mode (also a minor challenge), with SELinux enabled (required), and while I likely will need fapolicyd, I'm not even going to attempt that at this time (though I'll be happy to help once POSIX is re-enabled!). The systems need a particular mounting umask (mp_umask), and preferably other default umask (seemingly mutually exclusive, I'll open an issue about this). By attempting to set the sticky bit, we found that it wasn't being obeyed (setfacl, using xattr), as files/folders don't get created with the relevant users and/or groups (local or remote, sadly). While we have integrated with a remote LDAP (Active Directory actually), it doesn't matter, as even local groups aren't obeying the sticky bit as per this issue, and the fork mentioned in #1589 seems dead (not updated in 9 months). And even if it were, the administrative burden and overhead of building ourselves would be more than we would want to undertake unless it was a guaranteed fix for compliance reasons (excepting an RPMSPEC file that we can easily maintain, again, which while we can create one, it's a compliance thing....).

Sadly, certain types of chroot over S3FS is also broken at this time (I'll open an issue for that as well, explaining why). Likely due to POSIX compatibility problems.

But hopefully SOON. As EFS has its own problems (the 16 group limit that NFS has for instance!), and other filesystems are cost-prohibitive!

I would contribute patches, but in this particular case, I don't actually know where to begin.

@michaelsmoody commented on GitHub (Sep 16, 2022): This is one of an unfortunate _number_ of blocking issues that is stopping me from using S3FS in a production implementation and has, well, (and I really hate to say this, because it sounds....unforgiving) caused a waste of around 3 days of work chasing various bugs and problems. I'll be opening bug reports about them, but, this one is a deeply blocking issue (POSIX compatibility being a complete necessity). Long story short, we've setup an Amazon Linux 2 _3 system cluster_ running S3FS against an S3 bucket. All of which is in GovCloud (that was a minor adventure as well). The systems are in FIPS mode (also a minor challenge), with SELinux enabled (required), and while I likely **will** need fapolicyd, I'm not even going to attempt that at this time (though I'll be happy to help once POSIX is re-enabled!). The systems need a particular mounting umask (mp_umask), and preferably other default umask (seemingly mutually exclusive, I'll open an issue about this). By attempting to set the sticky bit, we found that it wasn't being obeyed (setfacl, using xattr), as files/folders don't get created with the relevant users and/or groups (local or remote, sadly). While we have integrated with a remote LDAP (Active Directory actually), it doesn't matter, as even local groups aren't obeying the sticky bit as per this issue, and the fork mentioned in #1589 seems dead (not updated in 9 months). And even if it were, the administrative burden and overhead of building ourselves would be more than we would want to undertake unless it was a guaranteed fix for compliance reasons (excepting an RPMSPEC file that we can easily maintain, again, which while we can create one, it's a compliance thing....). Sadly, certain types of chroot over S3FS is also broken at this time (I'll open an issue for that as well, explaining why). Likely due to POSIX compatibility problems. But hopefully SOON. As EFS has its own problems (the 16 group limit that NFS has for instance!), and other filesystems are cost-prohibitive! I would contribute patches, but in this particular case, I don't actually know where to begin.

kerem commented

2026-03-04 01:45:38 +03:00

Author

Owner

@ggtakec commented on GitHub (Sep 25, 2022):

@michaelsmoody
Implemented POSIX ACL compliant behavior in PR #2039.
If you can, please try it.
Thanks in advance for your assistence.

@ggtakec commented on GitHub (Sep 25, 2022): @michaelsmoody Implemented POSIX ACL compliant behavior in PR #2039. If you can, please try it. Thanks in advance for your assistence.

kerem commented

2026-03-04 01:45:38 +03:00

Author

Owner

@ggtakec commented on GitHub (Oct 22, 2022):

Sorry for the delay in replying.
Merge #2039.
I believe this merge has resolved the issue.
If the problem still persists, please repoen or post a new issue.

@ggtakec commented on GitHub (Oct 22, 2022): _Sorry for the delay in replying._ Merge #2039. I believe this merge has resolved the issue. If the problem still persists, please repoen or post a new issue.