Skip to contentSkip to conversation

ACLs

DISCUSSION Lukas Hejtmanek 2 participants 2 messages Aug 5, 2010

Subsystems (2)
lore
Share & tools
lore
#0 lore raw

Hello,

I use nfs4-acl-tools-0.3.3 and I get some oddities when setting the ACL:

$ nfs4_getfacl test
A::OWNER@:rwatTcCy
A::xhejtman@META:rtcy
A::GROUP@:tcy
A::EVERYONE@:tcy
$ nfs4_setfacl -s "A::ludek@META:R" test
$ nfs4_getfacl test
D::OWNER@:r
A::OWNER@:tTcCy
A::ludek@META:rtcy
A::GROUP@:tcy
A::EVERYONE@:tcy

is this something expected or buggy acl-tools?

Signature · 1 line
Lukáš Hejtmánek
#1 lore raw
Quoted 17 lines · Lukas Hejtmanek

Hello,

I use nfs4-acl-tools-0.3.3 and I get some oddities when setting the ACL:

$ nfs4_getfacl test
A::OWNER@:rwatTcCy
A::xhejtman@META:rtcy
A::GROUP@:tcy
A::EVERYONE@:tcy
$ nfs4_setfacl -s "A::ludek@META:R" test
$ nfs4_getfacl test
D::OWNER@:r
A::OWNER@:tTcCy
A::ludek@META:rtcy
A::GROUP@:tcy
A::EVERYONE@:tcy
Quoted 1 line

is this something expected or buggy acl-tools?

NFSv4 ACLs deny by default. Thus the ACL "A::ludek@META:R" denies permission to everyone else--including the owner of the file, if the owner is not ludek.

The linux server has no way to store in its filesystem an acl that says that; it *always* checks permissions for the owner before checking any user permissions.

So the server decides it's safer to be pessimistic and adds that first DENY....

Arguably the server could be less paranoid here. But we'll always have oddities like this as long as it doesn't have NFSv4 ACLs to work with on the exported filesystem. (Somebody's working on that.)

Workaround for now is probably just to always set the OWNER permissions to be at least as permisive as anyone else's. Or just add the "A::ludek@META:R" ace instead of replacing the ACL wholesale (which is what "-s" does).

(And then you'll still get ONWER, GROUP, and EVERYONE ACEs added on, but they won't be as silly.)

--b.