Constructing a NFSv4 ACL from POSIX mode bits
Subsystems (2)
Bruce,
In looking at http://tools.ietf.org/html/draft-ietf-nfsv4-acl-mapping-05, it states that when mapping the write bit, only for the owner do we set ACE4_WRITE_ACL.
Back in version 00, it is open as to whether we can also set it for the group and other if they have the write bit set.
I looked back at the NFSv4 WG aliases and I see some discussion from Lisa on how Solaris only ever sets it for the owner due to POSIX restrictions via chmod(). So, now I know how another server does it.
What does the Linux server do in this case?
Thanks,
Tom
Signature · 1 line
[email protected], ex-cfb
Quoted 4 lines · Tom
In looking at http://tools.ietf.org/html/draft-ietf-nfsv4-acl-mapping-05, it states that when mapping the write bit, only for the owner do we set
ACE4_WRITE_ACL.
Quoted 8 lines
Back in version 00, it is open as to whether we can also set it for the group and other if they have the write bit set.
I looked back at the NFSv4 WG aliases and I see some discussion from Lisa on how Solaris only ever sets it for the owner due to POSIX restrictions via
chmod(). So, now I know how another server does it.What does the Linux server do in this case?
The Linux server does what's described in the above draft:
unconditionally sets NFS4_ACE_WRITE_ATTRIBUTES | NFS4_ACE_WRITE_ACL on an OWNER@ ALLOW ACE, and nowhere else.
--b.
Quoted 6 lines · Tom
Bruce,
In looking at http://tools.ietf.org/html/draft-ietf-nfsv4-acl-mapping-05, it states that when mapping the write bit, only for the owner do we set
ACE4_WRITE_ACL.
Quoted 6 lines
Back in version 00, it is open as to whether we can also set it for the group and other if they have the write bit set.
I looked back at the NFSv4 WG aliases and I see some discussion from Lisa on how Solaris only ever sets it for the owner due to POSIX restrictions via
chmod(). So, now I know how another server does it.
This has changed. I wrote this up here:
http://cryptonector.com/2011/11/zfs-aclchmod-interactions-in-solaris-11/
IIRC all ACEs for anything other than OWNER@ (or a user of the same name/ID) contribute to the group bits of the mode, the EVERYONE@ entry contributes to the world bits of the mode, and the OWNER@ and/or user ACEs for the owner name/ID contribute to the owner bits of the mode.
The new scheme is really much simpler and more natural than everything else tried before.
Nico
--
Quoted 18 lines · Nico Williams
Quoted 6 lines · Tom
Bruce,
In looking at http://tools.ietf.org/html/draft-ietf-nfsv4-acl-mapping-05, it states that when mapping the write bit, only for the owner do we set
ACE4_WRITE_ACL.Quoted 6 lines
Back in version 00, it is open as to whether we can also set it for the group and other if they have the write bit set.
I looked back at the NFSv4 WG aliases and I see some discussion from Lisa on how Solaris only ever sets it for the owner due to POSIX restrictions via
chmod(). So, now I know how another server does it.This has changed. I wrote this up here:
http://cryptonector.com/2011/11/zfs-aclchmod-interactions-in-solaris-11/
Quoted 7 lines
IIRC all ACEs for anything other than OWNER@ (or a user of the same name/ID) contribute to the group bits of the mode, the EVERYONE@ entry contributes to the world bits of the mode, and the OWNER@ and/or user ACEs for the owner name/ID contribute to the owner bits of the mode.
The new scheme is really much simpler and more natural than everything else tried before.
Sounds reasonable.
But Tom was asking above only about ACE4_WRITE_ACL. And possibly only in the legacy case. (Does ZFS have a real ACE4_WRITE_ACL bit?)
--b.
Quoted 2 lines · J. Bruce Fields
But Tom was asking above only about
ACE4_WRITE_ACL. And possibly only in the legacy case. (Does ZFS have a realACE4_WRITE_ACLbit?)
Ah, oops. That's trickier. The examples don't say (or I'm not seeing it). IMO the most reasonable thing to do is to make chmod mask away the ACE4_WRITE_ACL bits of non-OWNER@/non-owner-user ACEs, but subsequent ACL writes can restore ACE4_WRITE_ACL without contributing to the w group or world bits of mode.
That is: to make aclmode=mask most natural and usable a chmod must have the expected POSIX behavior of taking away or granting access, but never granting anything like ACE4_WRITE_ACL to non-owners, while an ACL write should should be able to grant much more access than chmod and it should compute a new mode that is as close as possible to the new ACL. This requires storing a mode, an ACL, and one bit to indicate whether the ACL was set after the mode or the mode after the ACL.
Nico
--
Quoted 10 lines · Nico Williams
Quoted 2 lines · J. Bruce Fields
But Tom was asking above only about
ACE4_WRITE_ACL. And possibly only in the legacy case. (Does ZFS have a realACE4_WRITE_ACLbit?)Ah, oops. That's trickier. The examples don't say (or I'm not seeing it). IMO the most reasonable thing to do is to make chmod mask away the
ACE4_WRITE_ACLbits of non-OWNER@/non-owner-user ACEs, but subsequent ACL writes can restoreACE4_WRITE_ACLwithout contributing to the w group or world bits of mode.
Quoted 8 lines
That is: to make aclmode=mask most natural and usable a chmod must have the expected POSIX behavior of taking away or granting access, but never granting anything like
ACE4_WRITE_ACLto non-owners, while an ACL write should should be able to grant much more access than chmod and it should compute a new mode that is as close as possible to the new ACL. This requires storing a mode, an ACL, and one bit to indicate whether the ACL was set after the mode or the mode after the ACL.
I was with you up to the "one bit to indicate...". That doesn't sound necessary to implement the behavior you describe.
--b.