Subject: Re: [nfsv4] zapping an ACL

From: Rick Macklem <[email-masked]>
Date: Mon, 1 Dec 2008 11:48:09 -0500 (EST)

On Sun, 30 Nov 2008, Peter Varga wrote:

> In Windows, an empty ACL means no one has access. No ACL means everyone
> has access.
>
> http://msdn.microsoft.com/en-us/library/aa446597(VS.85).aspx
>
> "If a Windows object does not have a discretionary access control list
> (DACL), the system allows everyone full access to it. If an object has a
> DACL, the system allows only the access that is explicitly allowed by
> the access control entries (ACEs) in the DACL. If there are no ACEs in
> the DACL, the system does not allow access to anyone."
>
>
> NFSv4.1 seems to confirm this semantic for NFS as well:
> "For example, an empty ACL denies all permissions, but the server should
> allow the owner's SETATTR to succeed even though WRITE_ACL is implicitly
> denied."
>
>
> It appears to me there is no way to delete an ACL in NFSv4 or 4.1 - but
> since the ultimate goal is to establish some permissions on the object,
> perhaps it's sufficient for the client to simply issue a SETATTR with
> the desired mode bits in order to get the desired effect.
>
Yea, I was afraid that was the case. For now, I'll code the deletion as
ENOTSUP.

It does bring up the question of whether or not being able to delete
an ACL is something NFSv4 should support?

One cheezey way to do it, without changing the XDR, would be to define
ACL deletion as setting an ACL with a single ACE with a zero length
"who" field. (I ran across the zero length "who" field, since that is
what some Netapp filers do when they fill in the ACE field in a write
delegation reply. I assume it means "no valid ace".)

I've cc'd the guys that are doing ACLs for FreeBSD, in case they have
some insite w.r.t. deletion of an ACL should be supported.

Thanks for the reply, rick

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/nfsv4

---

From: "Noveck, Dave" <[email-masked]>
Date: Mon, 1 Dec 2008 14:35:16 -0500

> the desired mode bits in order to get the desired effect.

At least in 4.1, that will not have the desired effect.

Suppose I have a file owned by dave who is part of group dngroup and
where the mode bits allow the owner to write and the group to read.

If I have an acl that allows fred (among others) to read, then setting
the mode bits will not affect the ace for fred.  It will only affect the
ace's for @owner and @group (and maybe dave and dngroup).  As far as I
understand, the ace for fred will be left alone.

If you set an acl with three ace's, for @owner, @group, and @other,
whose access bits reflect the mode, you have the same permissions as you
would have by deleting the acl.  It doesn't give you the space back, but
I think that a file system could choose to optimize that case and delete
the acl.  The acl attribute would show up as three ace's that matched
the mode, and so would formally be present, even though you need not
have any space actually devoted to the acl on disk.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Benny Halevy
Sent: Sunday, November 30, 2008 1:35 AM
To: Rick Macklem
Cc: [email-masked]
Subject: Re: [nfsv4] zapping an ACL

On Nov. 28, 2008, 23:23 +0200, Rick Macklem <[email-masked]>
wrote:
> I've been working on adding ACL support to my Mac OS X client and I've

> just noticed that their VFS specifies deletion of an ACL for a file at
> times. Now, looking at RFC3530, it's not obvious how this is done for
> NFSv4.
> 
> The most obvious way is to do a Setattr Op with an ACL that has a zero
> length ACE list.
> 
> Is this correct, or does a zero length ACE list mean something other
than
> "get rid of the ACL"?

Rick, is there (or should the be) any noticeable difference
for the client between a deleted ACL and an empty one?
Assuming there isn't any, I see no issue with deleting the ACL
by sending a setattr for an empty ACL.

Benny

> 
> Thanks in advance for any help, rick
>

---

From: Rick Macklem <[email-masked]>
Date: Tue, 2 Dec 2008 11:45:20 -0500 (EST)

On Mon, 1 Dec 2008, Edward Tomasz Napierala wrote:

> On 1201T1148, Rick Macklem wrote:
>
> [..]
>
> No idea how this looks like from the protocol point of view, but here is
> how it works 'locally' in FreeBSD NFSv4 ACL implementation: first, it is
> not possible to remove all ACEs.  Attempt to remove last one will result
> in error.  Removing ACL, as done by "setfacl -b", simply brings the ACL back
> to the "canonical six" state by replacing existing ACL entries with six
> new, computed from the file mode; it's the same "canonical six" entries
> that one can see on every file without any ACL explicitly set or inherited,
> i.e. on files without "+" after the mode field in "ls -al" output.  AFAIK
> this is the same thing SunOS does.
>
Thanks a lot. I think, based upon the above and Dave Noveck's response, 
that I'll code this case as setting an ACL that represents the mode bits.
(I'll also probably crib your code to generate that ACL.:-)

Thanks to both Edward and Dave. Have a good week, rick

---

From: Edward Tomasz Napierala <[email-masked]>
Date: Tue, 2 Dec 2008 23:05:24 +0100

> (I'll also probably crib your code to generate that ACL.:-)

Please see kern/subr_acl_nfs4.c:acl_nfs4_is_trivial().  You just need to do:

struct acl aclp = acl_alloc();
acl_nfs4_sync_acl_from_mode(aclp, mode, file_owner_id);

-- 
If you cut off my head, what would I say?  Me and my head, or me and my body?

---

From: Edward Tomasz Napierala <[email-masked]>
Date: Mon, 1 Dec 2008 18:48:05 +0100

[..]