ACLs not working in allow_other mode?

[hstock]

Since allow_other sets default_permissions, which according to man fuse does not honour ACLs - does this mean ACLs are also broken for gocryptfs when using allow_other?

AFAIK the fuse kernel module can check ACLs in newer kernels (since 4.9?) when the file system registers as ACL supporting. This seems to be implemented in libfuse3. But since gocryptfs uses go-fuse, I don't know if it is implemented there as well.

In my setup it looks like ACLs are visible for tools, but not honoured for permission checks.

Could you clarify the state of ACL support and if this might be improved in the 2.0 rewrite?

[CTDragon]

I noticed that one of the latest changelogs mentioned ACL support was working so after a year or more of abandoning this as a solution I decided to give this a try again. I was similarly confused that I could set ACLs but they didn't seem to make any difference for permission checks. I have to chown or chmod --7. Anything less than 7 (rwx) will not allow me to access the files when not an owner.. even 6 (rw). Granting permission using setfacl seems to work and getfacl shows what I expect, but it does not affectively grant permissions.

I tried this on Beta2 as well. Seems really fast.

[rfjakob]

Hmm. From man fuse:

       default_permissions
              [...]
              This  mount  option is activated implicitly if the filesystem
              enables ACL support during the  initial  feature  negotiation
              when opening the device fd. In this case, the kernel performs
              both ACL and standard unix permission checking.

Maybe we don't signal ACL support correctly. Will check.

[rfjakob]

Closing in favor of older ticket #536

[rfjakob]

I must apologise for the changelog entry "Enable ACL support". ACL support is very incomplete, and I have added a warning to this changelog entry now:

Warning 2021-02-07: This feature is incomplete! Do not use ACLs before gocryptfs v2.0 final! Reading and writing ACLs works, but they are not enforced or inherited (#542)

I'm working on getting this fixed.