Subject: [nfsv4] Constructing a NFSv4 ACL from POSIX mode bits

From: "Haynes, Tom" <[email-masked]>
Date: Tue, 24 Jul 2012 12:33:49 -0700

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-masked], ex-cfb

---

From: "J. Bruce Fields" <[email-masked]>
Date: Tue, 24 Jul 2012 15:53:01 -0400

> 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.

---

From: Nico Williams <[email-masked]>
Date: Tue, 24 Jul 2012 15:00:57 -0500

> 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
--

---

From: "J. Bruce Fields" <[email-masked]>
Date: Tue, 24 Jul 2012 16:09:32 -0400

> The new scheme is really much simpler and more natural than everything

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.

---

From: Nico Williams <[email-masked]>
Date: Tue, 24 Jul 2012 15:29:07 -0500

> 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
--

---

From: "J. Bruce Fields" <[email-masked]>
Date: Wed, 25 Jul 2012 09:29:27 -0400

> indicate whether the ACL was set after the mode or the mode after the

I was with you up to the "one bit to indicate...".  That doesn't sound
necessary to implement the behavior you describe.

--b.