Subject: RE: [nfsv4] NFSv4 ACLs: (acl, masks) pairs

From: "Yoder, Alan" <[email-masked]>
Date: Wed, 30 Aug 2006 17:04:57 -0700

Netapp has had both ACLs and modes for going
on ten years.  Our behavior is closest to 
option 2, and has worked well for us.

What we do--boiled down--is to keep track
of which is *active*, the ACL or the mode.
The active one is determined by which is
last set.  This is what is used to determine
authorization for file access.  

   Doing this reduces the mapping problem to a 
   display issue, i.e. the mapping exists only
   for the purposes of GETATTR and READ_ACL.   
   Clients which do these may get a slightly 
   different impression of what might be allowed
   than is actually true.  This has not been a
   problem in the field except in the case of v2
   clients that I mentioned some time ago.

But in all cases, there is no possibility of
distortion during the actual authorization process.
The mode or ACL is set to exactly what the
client specifies, and is exactly what is used.

It's true that SETATTR | READ_ACL | WRITE_ACL | GETATTR
may result in something more restrictive than what was
started out with in some cases.  This has not proved 
to be an issue.  Admins are about the only people who do
this, and they generally don't care if they end up with
something slightly more restrictive than the original.

My principal requirement for a mask model is that it is
optional.  Our backup system uses named attributes to
write out all our special metadata.  Since this group
is never going to standardize all of that, I don't 
have any interest in standardizing the little piece
of it that option 3 covers.

Alan

===============================================================
Alan G. Yoder                                    [email-masked]
Technical Staff                           
Network Appliance, Inc.                            408-822-6919
===============================================================

> -----Original Message-----
> From: J. Bruce Fields [mailto:[email-masked]] 
> Sent: Wednesday, August 30, 2006 4:36 PM
> To: Lisa Week
> Cc: [email-masked]; Andreas Gruenbacher
> Subject: Re: [nfsv4] NFSv4 ACLs: (acl, masks) pairs
> 
> On Wed, Aug 30, 2006 at 03:34:57PM -0600, Lisa Week wrote:
> > So, since we have to solve the problem of applying a mode to an 
> > arbitrary NFSv4 ACL anyway, why would we add the additional 
> complexity 
> > of having a mask attribute as well?
> 
> Consider the case:
> 
> 	1. set the acl to (lisa:rw-:allow)
> 	2. set the mode to 000.
> 
> What do you return at this point?  There are a number of 
> choices, which
> would all represent the effective permissions correctly:
> 
> 	1. (lisa:---:allow)
> 
> 	2. ()			(empty acl--denies everything)
> 
> 	3. (lisa:rw-:deny,
> 	    lisa:rw-:allow)
> 
> The first two choices have the advantage of simplicity.  The third has
> the advantage that it preserves some information.
> 
> I'd prefer to have the option of doing 1 or 2, because option 3 gets
> more complicated as more users are added to the ACL.
> 
> The file_mask attribute allows me to do that, by allowing me to return
> option 1 or 2 in the normal case, but allowing me to return
> 
> 	1. ((lisa:rw-:allow), mask 000)
> 
> to the rare client that really cares about the full story.
> 
> --b.
> 
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nfsv4
> 

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

---

From: "J. Bruce Fields" <[email-masked]>
Date: Wed, 30 Aug 2006 22:38:31 -0400

> authorization for file access.  

Sounds reasonable.  (I'm curious how you handle
inheritance, though[1].)

> optional.

Definitely.

> Our backup system uses named attributes to

Right, so the question is exactly whether the mask is
a piece of metadata that's common or useful enough to
be worth providing a standard interface to in the
protocol.

I might not have thought it was; but when I see
implementations doing stuff like option 3:

        3. (lisa:rw-:deny,
	    lisa:rw-:allow)

by default, I start to get worried; if people
are really that anxious to preserve the mask
information, then we need a mask attribute.

I'd *much* rather give them a separate attribute
for that purpose than have servers automatically
inserting more deny's.

--b.

[1] inheritance: if your response to an open from a unix client (which
will always set the mode) is to just make the mode "active"
and ignore any ACL, then doesn't that mean that unix open's
end up always ignoring inherited ACLs?  Do you have some special
handling for this case?

---

From: "J. Bruce Fields" <[email-masked]>
Date: Wed, 30 Aug 2006 22:56:53 -0400

On Wed, Aug 30, 2006 at 10:38:31PM -0400, J. Bruce Fields wrote:
> by default, I start to get worried

And this is *not* just about being nice to Explorer.

The single simplest thing a user should be able to--from
a gui, from the commandline, from a script, whatever--is
give a named user or group some additional access to a
file; a user should be able to say "give bob write access",
and have something simple and sane happen.

It's very easy to implement such a thing when you've only
got ALLOW's to deal with--you just search through the
ACL for an ACE for "bob", and turn on write acess in it,
or add a new ACE if you need to.

Doing the same kind of stuff with an ACL with intermixed
ALLOW's and DENY's is a mess.

DENY's were a mistake to start off with.  The least we can
do is try to avoid adding them without the user explicitly
choosing to.

--b.

---

From: Andreas Gruenbacher <[email-masked]>
Date: Thu, 31 Aug 2006 23:57:14 +0200

Alan,

> authorization for file access.

do you have documentation that you could point me at for understanding what 
the server enforces and returns after mode SETATTR and ACL SETATTR?

I would like to understand how this implementation handles sequences of mode 
SETATTR, and ACL read-modify-write cycles.

Bruce's question how a mode SETATTR as part of a POSIX file create affects 
inherited ACLs is interesting case as well.

> My principal requirement for a mask model is that it is

I agree.

Thanks,
Andreas