Subject: Re: Interaction between mode bits and acls

From: Peter Staubach <[email-masked]>
Date: Tue, 9 Apr 2002 17:58:37 -0600 (MDT)

> 
> I dont see anything in the spec that talks about how the mode bits and acls 
should interact with each other if both 
> are present. I would say once an acl has been created on an object, all perm 
checks should be done relative to
> that and a best effort mapping should be done for the mode bits only to be 
used as display permissions such as
> when someone does an 'ls -l'. However there can be issues with accessing files 
if a user sets the permissions 
> using acls and another user on a different client (without acl support, can be 
v2/v3 client) tries to access the file 
> based on what he sees from 'ls -l'.
> 
> The other option of keeping them both consistent with each other at all times 
and doing permission checks using
> both doesn;t seem very appealing and also involves extra work on the part of 
the server.
> 
> Any suggestions or feedback on this issue would be appreciated. What are other 
implementations doing?

As of NFS Version 3, clients don't make access decisions based on
either ACL entries or mode bits.  They ask the server for pertinent
access rights.  It is up to the server to resolve `conflicts' between
the mode bits and any ACL entries.

The client should not be trying to determine access rights on its own.
It can't correctly determine them.  Root mapping on a UNIX based server
is a good example of why clients can not correctly determine access
rights.  There are other forms of id mapping as well.

		ps

---

From: "Khan, Saadia" <[email-masked]>
Date: Tue, 9 Apr 2002 17:31:35 -0700

yes, this is all in relation to what the server would do in these
situations.

Saadia

> -----Original Message-----
> From: Peter Staubach [mailto:[email-masked]]
> Sent: Tuesday, April 09, 2002 4:59 PM
> To: [email-masked]; [email-masked]
> Subject: Re: Interaction between mode bits and acls
> 
> 
> 
> >

---

From: "Yoder, Alan" <[email-masked]>
Date: Wed, 10 Apr 2002 11:05:11 -0700

> I would suggest the following interpretation if the above is not true:
> 
> 1) ACLs are scanned in order, when an entry is found which
> matches the "user" (could be the user's group etc) and explicitly
> grants or denys the access method requested, scanning stops and the
> result is returned.

   Suppose the user requests rwx and one ACE grants
rw and another x?

Alan

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

---

From: "Khan, Saadia" <[email-masked]>
Date: Wed, 10 Apr 2002 11:08:50 -0700

that should be fine since all aces are scanned until all the 
requested access is either explicitly granted or something is
denied.

Saadia

> From: Yoder, Alan [mailto:[email-masked]]
> Sent: Wednesday, April 10, 2002 11:05 AM
> To: [email-masked]'
> Subject: FW: Interaction between mode bits and acls
> 
>

---

From: [email-masked]
Date: Wed, 10 Apr 2002 14:13:31 -0400

Typically, ACL entries are cumulative, so that one ACE granting RW and
another granting X would allow a user to gain RWX.  This could be from a
combination of user or group ACEs.  This assumes, of course, that some
earlier ACE didn't deny one of those accesses.

Tad Taylor
919-248-6374
Tie-Line 8-262-6374

-----Original Message-----
From: Yoder, Alan [mailto:[email-masked]]
Sent: Wednesday, April 10, 2002 2:05 PM
To: [email-masked]'
Subject: FW: Interaction between mode bits and acls

Alan

---

From: "Yoder, Alan" <[email-masked]>
Date: Wed, 10 Apr 2002 11:21:59 -0700

Yes, this is my understanding as well.  Carl's
wording could be construed to mean that an ACE
which explicitly grants all the requested access
rights is required.

Alan

> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, April 10, 2002 11:14 AM
> To: [email-masked]
> Subject: RE: Interaction between mode bits and acls
> 
>

---

From: Jim Rees <[email-masked]>
Date: Wed, 10 Apr 2002 14:22:51 -0400

My experience has been that acls are hard enough to understand, and putting
in "deny" bits makes them impossible to understand.  They are almost never
necessary in real life if you order your acl from most to least specific.

I assume we have deny bits because that makes nfs acls general enough to
export any underlying file system.  But I would urge anyone who is doing
their acl implementation from scratch to leave them out (the protocol allows
this).

By the way, I don't see anything in the spec about acl ordering.  It looks
like it's up to the client that sets the acl.

---

From: [email-masked]
Date: Wed, 10 Apr 2002 14:36:26 -0400

I would contend that "Deny" ACEs have their uses.  When ACEs can be
cumulative, they're necessary to obtain some desired outcomes (i.e., Don't
let "Joe" write to this file even if he is in the "XYZ" group).  You're
right in that the spec doesn't specify an ACL ordering (although it does say
that order is important when it talks about how ACEs are processed),
however, I would think it was up to the server to order the ACE entries.  A
client should not assume that the order in which they provide ACEs is
preserved.

---

From: "Noveck, Dave" <[email-masked]>
Date: Wed, 10 Apr 2002 11:47:19 -0700

Carl Beame wrote:
> On Tue Apr 09 23:47:18 2002, Khan, Saadia wrote:
> > Hi,
> > 
> > I dont see anything in the spec that talks about how the mode bits and
> > acls should interact with each other if both 
> > are present. I would say once an acl has been created on an object,
> > all perm checks should be done relative to
> > that and a best effort mapping should be done for the mode bits only
> > to be used as display permissions such as
> > when someone does an 'ls -l'. However there can be issues with
> > accessing files if a user sets the permissions 
> > using acls and another user on a different client (without acl
> > support, can be v2/v3 client) tries to access the file 
> > The other option of keeping them both consistent with each other at
> > all times and doing permission checks using
> > both doesn;t seem very appealing and also involves extra work on the
> > part of the server.
> > 
> > Any suggestions or feedback on this issue would be appreciated. What
> > are other implementations doing?
> > 

> The original intention (at least what I thought it should be) was that
> the server would implement what it's own filesystem security would
> allow and then translate this to the NFS V4 ACL specification. 

> grants or denys the access method requested, scanning stops and the

Some people have brought up the case in which more than one type of
access is required by an operation.  I assume that open for read-write,
for example, would fail if you don't have both read and write access.

So perhaps we need to say something like:

     ACLS are scanned in order, with each entry that applies to the
requestor 
     (by virtue of having matching user or a group to which the requestor
     belongs) being processed, until either, the processed entry denies
     one of the types of access being requested, or a set of processed 
     entries are encountered which, taken together, allow all of the types
     of requested access. 

> 2) If no ACL is found which matches the "user" and the requested
> access method, the mode bits are then consulted.

What about the case in which I am asking for read and write and the
ACL allows me write?  One way to handle this is to consult the mode
bits for read and write (ACL's and mode bits are alternatives), while
the other is to consult the mode bits just for read (the mode bits act
as an extension of the ACL, in that each of the three sets of bits
within the modes has an obvious mapping to an ACE, with those three
ACE's being consolted if the ACE's in the ACL proper don't resolve 
the matter, and assuming that the server supports the mode attribute).

---

From: [email-masked]
Date: Wed, 10 Apr 2002 15:04:03 -0400

Actually, as I think about the original question below, I realize that it's
presupposing the existance of mode bits in addition to ACLs.  That might not
be the case for all servers, so I don't think the spec should say anything
about it.  

Furthermore, if there's an "additional" set of attributes (e.g., mode bits)
that can apply to a file, then the user has to address those attributes as
well after setting an ACL.  Although, the spec doesn't really say that there
won't be other attributes on a file.

As for the wording of how ACLs are interpreted, I think the current wording
works pretty well.

---

From: "Noveck, Dave" <[email-masked]>
Date: Wed, 10 Apr 2002 12:13:31 -0700

> I would contend that "Deny" ACEs have their uses.

They certainly have their uses but are they good uses? :-)  

> When ACEs can be

It doesn't explicitly specify an order but I think the implication is
that there is an (obvious) order.  The ACL is defined as an array.  
When the spec says that entries are processed "in order" I can't read
that in any other way, than as saying that the order is that of the
(ascending) order of the associated indices.  

> however, I would think it was up to the server to order the ACE entries.

If the spec meant that it was up to the server to order the ACE entries
in some other order than that presented by the client, I would expect 
it to say so.  Also, if it were up to the server to choose an order of its
own, the spec would say so.  

> A

I don't see how he can avoid any such assumption.  If you specify
deny "Joe" and then allow group "XYZ", then you want to deny Joe
no matter what, where if you specified the other order, you want to 
allow all members of XYZ (even if one is Joe), but deny Joe if he
is not a member of XYZ.  Order makes a difference and you know what
you want (or at least it is possible you know what you want) and the
server has no way of knowing what you want except the order you specify.

---

From: "Noveck, Dave" <[email-masked]>
Date: Wed, 10 Apr 2002 12:46:09 -0700

> be the case for all servers, so I don't think the spec should say anything

The question is how to address the interaction of mode bits and acl's when
they both exist.  ACL's and mode bits are both recommended attributes.
As a practical matter, NFS-v4 servers that don't support mode bits are
not likely to be common in any case.

I'm not fixated on addressing this in the spec.  If people think this might
infringe on their creativity in handling these issues (although when
security
is involved, unrestrained creativity has its problems), we can leave this
out.  My concern is for the user.  If the user has mode bits and acls on 
a set of files and moves them from a brand-X NFS-v4 server to a brand-Y 
NFS-v4 (or a different release of brand-X) and things stop working or work 
differently, then he has his choice of cursing brand-X or brand-Y or the 
NFS-v4 working group, none of which is going to do him any good.  If we
all implement the same strategy, whether this is a requirement in the spec
or not, we are going to save users (and support people) a whole lot of 
heartburn.  I think a uniform strategy on this issue will be to the benefit
of the entire v4 community, even if the spec allows outliers to do something
else without being branded non-compliant.    

> won't be other attributes on a file.

Don't understand this.

---

From: "Yoder, Alan" <[email-masked]>
Date: Wed, 10 Apr 2002 13:13:02 -0700

> not likely to be common in any case.

   Don't mode bits need to override the ACL?  How
else does one deal with BACKUP OPERATOR privilege,
for example?

Alan

---

From: "Yoder, Alan" <[email-masked]>
Date: Wed, 10 Apr 2002 13:28:31 -0700

> In current systems that I am familar with, the mode bits are only
> consulted after all of the ACL entries are checked.
> 
> Are privileges like this expressed only in the mode bits and not
> in ACL entries?

   I may be a bit confused here.  Are the mode bits set
per file?  If so, what on earth are they for and why can't
the mode bits be put into ACEs?

   In NT, there are "privilege levels", I remember something 
similar in VMS.  They're orthogonal to ACLs, and are a property 
of the running process, not of any given file.  The BACKUP_OPERATOR
privilege in NT gives you godlike powers on files, including the
ability to change ownership.

Alan

---

From: [email-masked]
Date: Wed, 10 Apr 2002 16:29:35 -0400

I wasn't thinking about mode bits also being a recommended attribute, sorry.
I looked to make sure they weren't mandatory and forgot about looking there.
I agree with you that a well-defined algorithm is better than everyone
having their own solution.  Access control should be as deterministic as
possible for users.  That said, I believe that the existance of an ACL
should override what the mode bits say.  The access control check should be
one or the other, but not both.

That leaves open the issue of how changes to mode bits would be reflected in
ACLs.  The mode bits could be "translated" into ACL terms and added to the
ACL (I believe this is what the defunct POSIX spec did when a user did a
chmod on a file with an extended ACL, although that's an easier case).
Setting the mode bits could override (i.e., remove) the ACL, or we could
define a process for having both and coming up with an algorithm of how they
would be used simultaneously.

As for the point below about having to worry about both sets of attributes,
if I set an ACL that allows a user read access, do I have to make sure that
the mode bits don't also grant write access?  That is, if both values can
exist on a file and both be referenced when checking a user's access, do I
have to set both sets of attributes when I change access control rights?

-----Original Message-----
From: Noveck, Dave [mailto:[email-masked]]
Sent: Wednesday, April 10, 2002 3:46 PM
To: [email-masked]'; Noveck, Dave; [email-masked];
[email-masked]; Khan, Saadia
Subject: RE: Interaction between mode bits and acls

Don't understand this.

---

From: Jim Rees <[email-masked]>
Date: Wed, 10 Apr 2002 16:37:24 -0400

Think of mode bits as a very simple acl with three entries, one each for the
owner, a single group, and everyone else.  Each entry has three rights bits,
read, write/insert, and execute/lookup.  Mode bits are in the protocol as a
sort of backward compatibility hack.  They were used as a file protection
hint in older versions of nfs.

There is a fundamental conflict when you have both acls and mode bits.  I
have extensive experience with two systems that had both.  One of them
(Domain/OS) tried to map between them, and ended up being confusing and hard
to use.  The other (afs) ignored the mode bits and only used the acl, and
ended up being confusing and hard to use.  I think it's unfortunate that the
nfs v4 designers didn't learn from this experience and leave out the mode
bits, but I understand the constraints they were operating under.

---

From: "Khan, Saadia" <[email-masked]>
Date: Wed, 10 Apr 2002 13:40:09 -0700

> Sent: Wednesday, April 10, 2002 1:30 PM
> To: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]

I dont think the mode bits should be consulted when setting the acl.
What if the acl wants to remove the write permission allowed to a 
user before, just because the mode gave that permission doesn;t mean
that we should still keep it.

Also the mode bits have to be consistent with the acl as much as
possible, so whenever the acl is changed, the mode bits have to 
reflect that change too. This is necessary for all the other clients
including v2 and v3, who might do an 'ls -l' and then try to access
a file. However if the access is granted based on the acl, they might
be denied access.

Saadia

> > Actually, as I think about the original question below, I 
> realize that
> it's
> > presupposing the existance of mode bits in addition to 
> ACLs.  That might
> not
> > Furthermore, if there's an "additional" set of attributes 
> (e.g., mode
> bits)
> > well after setting an ACL.  Although, the spec doesn't 
> really say that
> there