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
--
[email protected], ex-cfb
On Tue, Jul 24, 2012 at 2:33 PM, Haynes, Tom <[email protected]> wrote:
> 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.
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
--
On Tue, Jul 24, 2012 at 03:00:57PM -0500, Nico Williams wrote:
> On Tue, Jul 24, 2012 at 2:33 PM, Haynes, Tom <[email protected]> wrote:
> > 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.
>
> 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.
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.
On Tue, Jul 24, 2012 at 3:09 PM, J. Bruce Fields <[email protected]> wrote:
> 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?)
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
--
On Tue, Jul 24, 2012 at 12:33:49PM -0700, Haynes, Tom wrote:
> 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?
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.
On Tue, Jul 24, 2012 at 03:29:07PM -0500, Nico Williams wrote:
> On Tue, Jul 24, 2012 at 3:09 PM, J. Bruce Fields <[email protected]> wrote:
> > 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?)
>
> 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.
I was with you up to the "one bit to indicate...". That doesn't sound
necessary to implement the behavior you describe.
--b.