Subject: Speaking of ACLs

From: [email-masked]
Date: Wed, 10 Apr 2002 15:13:49 -0400

Since NFSv4 allows ACEs to be inherited from a parent directory, shouldn't
the SETATTR operation allow setting ACLs to either add to or supersede an
existing ACL?  Just because you want to add something to an ACL doesn't mean
you want to remove the ACEs that were inherited.   I don't think I saw
anything in the spec other than setting (presumably replacing) an ACL.

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

---

From: Spencer Shepler <[email-masked]>
Date: Wed, 10 Apr 2002 14:36:33 -0500

> anything in the spec other than setting (presumably replacing) an ACL.

The NFSv4 attribute model is replace-only and hence this applies to
the ACL attribute.

-- 
Spencer

---

From: [email-masked]
Date: Wed, 10 Apr 2002 15:50:18 -0400

I don't think you can set an "ACE4_FILE_INHERIT_ACE" on a file, therefore if
a client did a GETATTR and then a SETATTR, an ACE might transition from
inherited to explicit.  Although the spec does not say that an ACE once
inherited will maintain this distinction, I think it's reasonable to
consider that a server would want to keep track of this.

-----Original Message-----
From: Spencer Shepler [mailto:[email-masked]]
Sent: Wednesday, April 10, 2002 3:44 PM
To: [email-masked]
Subject: Re: Speaking of ACLs

On Wed, [email-masked] wrote:
> That seems problematicin the face of inheritable ACEs.  Is there some
> fundamental reason why this is the case?  It would seem to be an easy
> extension to how ACLs are set.

The client can GETATTR, modify acls, SETATTR, right?

If the model were to change for the ACL attribute, what add "modes"
should there be?  Append, pre-pend, sort?  Based on the issues that
have been discussed with respect to ordering an interpretation it
seems best to leave the model as it is until we have more concrete
information from implementation experience.

> -----Original Message-----
> From: Spencer Shepler [mailto:[email-masked]]
> Sent: Wednesday, April 10, 2002 3:37 PM
> To: [email-masked]
> Subject: Re: Speaking of ACLs 
> 
> 

-- 
Spencer

---

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

Trying to enumerate modes is a loser.

The client can implement his own modification rules, except
for the atomicity issue.  If this is a problem, I think the
best way to address it would be a COMPARE_AND_SWAP_ATTR
operation.  But that's something for a minor version, if
it turns out to be necessary.

-----Original Message-----
From: Spencer Shepler [mailto:[email-masked]]
Sent: Wednesday, April 10, 2002 3:44 PM
To: [email-masked]
Subject: Re: Speaking of ACLs

-- 
Spencer

---

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

What do you mean by "an ACE might transition from inherited to explicit?"

---

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

If a client wanted to add to an ACL and did a GETATTR, then added something
to the ACL field and then turned around and did a SETATTR, the server isn't
going to be able to tell that part of that ACL used to be inherited.  Now,
this argument presupposes that the inherited ACEs are explicitly added to a
file when it is created, rather than determined "on-the-fly".  I suppose
that's up to the server to decide what to do.

If you believe that explicitly added ACL entries should have preference over
inherited ACL entries, then keeping track of the inherited status does
matter.

--Tad

---

From: [email-masked]
Date: Wed, 10 Apr 2002 16:18:22 -0400

I believe that's exactly what NTFS does (at least as of Win2K and later).
I'll leave it to the audience to determine if that's an example of a
"working filesystem".

-----Original Message-----
From: Yoder, Alan [mailto:[email-masked]]
Sent: Wednesday, April 10, 2002 4:12 PM
To: [email-masked]'; [email-masked];
[email-masked]
Subject: RE: Speaking of ACLs

> consider that a server would want to keep track of this.

   To my knowledge, the equivalent of { READATTR, munge ACL,
SETATTR }, resulting in an explicit ACL, is the current
standard.

   You're proposing a kind of "mixed" ACL, in
which some ACEs are inherited and others are
explicitly set?  Are there any examples of working 
filesystems which do this?  What problem does it 
solve?

Alan

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

---

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

The only aces that have precedence over other aces are those that appear
earlier in the acl.  It makes no difference whether the ace was inherited or
set explicitly.  I think the spec is pretty clear on that.

I also don't see any reason why the server should care.  If the entire acl
is inherited, like in Domain/OS, the server might want to reference count
them and do copy-on-write as an optimization, but that's an implementation
issue that's invisible to the client and to the protocol.

If the client has some bizarre reason to order the acl based on whether the
entries were inherited or not, I think the burden is on the client to figure
that out.

---

From: [email-masked]
Date: Wed, 10 Apr 2002 16:33:38 -0400

The spec says nothing about how ACEs should or could be ordered, only that
they are evaluated in order.  It says nothing about maintaining the order
set by the user in a SETATTR call.  NTFS clearly thinks explicit versus
inherited makes a difference and to the extent that NFSv4 is trying to make
the users life easier in a multi-protocol environment, I believe that NFSv4
should take that into consideration as well.

---

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

While it's true that the spec says nothing about maintaining the same acl
that the client specified, it would be so strange, unexpected, and wrong for
the server to re-order the acl that I don't think we need to explicitly say
that in the spec.

The spec also doesn't say that the server must not change the data bits that
a client writes to a file, but I think we all know that's the case.

---

From: [email-masked]
Date: Wed, 10 Apr 2002 16:48:49 -0400

I realize that  the INHERIT_ACE flag is for directories, but the point is
that some OSes keep track of whether or not an ACE was inherited.  It's not
unreasonable for NFSv4 to be compatible with that notion.  Currently, it is
not.

-----Original Message-----
From: Carl Beame [mailto:[email-masked]]
Sent: Wednesday, April 10, 2002 4:37 PM
To: [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: RE: Speaking of ACLs

The intent of the INHERIT_ACE flag was for an ACE which is ONLY on a
directory and has NO meaning for the access to the directory. 

Given a directory with an ACE with the INHERIT_ACE flag set. Any File
created in the Directory receives, on creation, an ACE which is a copy
of the ACE in the parent directory with the INHERIT_ACE flag removed. Any
Directory created in the Directory receives on creation an ACE which
is a copy of the ACE in the parent directory with the INHERIT_ACE flag
removed AND a copy of the ACE in the parent directory with the
INHERIT_ACE flag set. This allows for propogation of ACEs.

- Carl

---

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

why do they want to keep track of that?

Saadia

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

---

From: Jim Rees <[email-masked]>
Date: Wed, 10 Apr 2002 17:03:28 -0400

I think it is.  The spec says "ACE4_FILE_INHERIT_ACE Can be placed on a
directory" but it does not say that it cannot be placed on a file.  It would
have no meaning when placed on a file, but if some client wanted to use that
bit for something, I don't see why it shouldn't be able to.

---

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

Sorry for my earlier confused questions.

Here is a link giving the presumably official MS party
line on how inherited ACLs are processed.

http://www.win2000mag.com/Articles/Index.cfm?ArticleID=8452

"Win2K and SCM use the sequence in which the Security Reference Monitor (SRM)
evaluates ACEs to handle conflicts between inherited and noninherited
permissions. The Win2K and SCM SRM component approves or denies access when a
program tries to open an object. The SRM processes noninherited permissions
first, then inherited permissions. The SRM processes these entries one at a
time, comparing the specified user or group SID in the ACE with the SIDs in the
program's access token.

When you run a program, it receives an access token consisting of your SID and
the SIDs of groups that you belong to. When the SRM encounters an ACE that
matches a SID in your access token, the SRM evaluates that ACE's permissions. If
the ACE explicitly denies the type of access your program is requesting, the SRM
immediately exits the loop, denying access. Otherwise, the SRM accumulates the
permissions the ACE granted. Then, the SRM checks whether it has accumulated all
the permissions that the program requested. If the SRM has accumulated all
requested permissions, it grants the requested access; if the SRM hasn't
accumulated all requested permissions, it processes the next ACE. If the SRM
reaches the end of the ACL before accumulating the requested permissions, the
SRM exits, denying access. Therefore, when conflicts between noninherited and
inherited ACEs exist, the noninherited ACEs win."

If NFSv4 wants to be different from this, it would be nice if 
there were a compelling reason why.

Alan

> Sent: Wednesday, April 10, 2002 2:13 PM
> To: [email-masked]; [email-masked]; [email-masked];
> On Wed Apr 10 22:03:50 2002,  wrote:
>   I want
> > to
> > craft an ACL that allows and denies the right set of accesses to the
> > right
> > set of people and apply it to a directory structure just once.  So,
> > imagine
> > I create a directory for some engineering project and deny access to
> > the
> > Marketing group so they don't tell customers about 
> something too soon.
> >  At
> > some point, I might have a file in the directory structure 
> that I want
> > a
> > Marketing person to read.  Therefore, I'll add an ACL entry that
> > allows that
> > Marketing person read access to the file.  Since this is an explicit
> > ACE, it
> > takes precedence over the inherited ACE that would have 
> denied access.
> 
> Not true! The file which you want to allow access when it is created
> will have an ORDINARY ACE which prohibits access to the Marketing
> Department. To change this you use Microsofts tools which below the
> surface will read the existing ACEs and add an ALLOW ACE for the
> Marketing person before the ACE for disallowing the Marketing
> Departmant and then rewrite the ACL to disk.
> 
> > 
> > The idea of ACLs automatically propagating through a directory
> > structure is
> > appealing, the question is in how it's handled.  When POSIX 
> did it, an
> > inherited ACL because just like any other ACL entry (as I recall). 
> > When
> > Microsoft did it, they keep track of explicit versus inherited.  
> > They  may
> > actually compute the inherited ACEs on-the-fly, I don't know.
> 
> No.  ACEs on parent directories have NO bearing on the ACE of the
> file. The only time it does is at the instant of creation. If a client
> NFS wants to set a specific ACE on a newly created file it should read
> the ACEs from the file just after creation to see what inherited ACEs
> the server gave it.
> 
> 
> - Carl
>

---

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

Fair enough, but we still need to make the spec clearer about how 
different permission types interact with each other so that 
clients see the same behavior from server to server.

So maybe we should concentrate more on how to make the current stuff
work properly and leave additional features for minor versions.

Saadia

> From: Dan Trufasiu [mailto:[email-masked]]
> Sent: Wednesday, April 10, 2002 3:18 PM
> I know that I try the same thing in the past and I make some 
> people unhappy.
> I will try again. I learned in school that a protocol has to 
> described an
> interaction between a client and a server. Looks to me that 
> now every time
> that we run in a problem that require some difficult implementation
> decisions we are trying to force a change into the protocol. 
> There are a lot
> of proposal for new messages, new flags. I know that we can 
> not release a
> broken specification, but adding new stuff will create new 
> problems new
> incompatibilities. And we can go this way forever.
> Like Jim, I strongly oppose any change in the protocol. Don't 
> try to save a
> client that doesn't know what he is doing.
> 
> Thanks
> 
> Dan
> 
> 
> 
> > From: [email-masked]
> > [mailto:[email-masked]]On Behalf Of Jim Rees
> > Sent: Wednesday, April 10, 2002 5:38 PM
> > I would be strongly opposed to changing the spec now to add
> > Microsoft's odd
> > distinction between inherited and non-inherited acls.  I
> > would also argue
> > that no change is needed, because a client already has a way
> > to determine
> > whether an ace was inherited or not, and a way to specify
> > what order the
> > aces appear in the acl.
> >
> > Making acls any more complicated than they already are is a 
> bad idea.
> >
>