Subject: RE: [nfsv4] ACL discussion wrapup

From: "Khan, Saadia" <[email-masked]>
Date: Sat, 11 Nov 2006 12:58:50 -0800

Just to confirm, in case there is no acl on the dir and no acl is being
passed into the create/mkdir call, then the new file/dir will only
contain mode bits and not an acl, right?

The other thing I want to clarify is what happens if a dir has an OWNER@
ace that is directory inherit and now a new dir gets created, do we set
an OWNER@ ace on the new dir (with the inherit flags) as well as a user
ace that maps to the owner (without the inherit flags) or do we just set
an OWNER@ ace with the inherit flags on the new dir?

My apologies if this has been clarified in the new draft and/or previous
emails.

Thanks.
Saadia 

-----Original Message-----
From: J. Bruce Fields [mailto:[email-masked]] 
Sent: Friday, November 10, 2006 2:59 PM
To: Andreas Gruenbacher
Cc: Yoder, Alan; [email-masked]
Subject: Re: [nfsv4] ACL discussion wrapup

On Thu, Nov 09, 2006 at 02:10:03AM +0100, Andreas Gruenbacher wrote:
> Hello,
> 
> On Thursday 09 November 2006 01:45, Yoder, Alan wrote:
> > Hi,
> >
> >    Attached is the Word doc I put together in the process of 
> > clarifying my thinking on the attributes proposed by Bruce.  Per the

> > discussion today, it seems we should also add an optional 
> > ACL4_DEFAULTED flag, to indicate that the ACL was ginned up based on

> > a file creator's credentials, because the parent directory didn't 
> > have an ACL at the time of creation.  It would indicate to a client 
> > doing auto inheritance that it is okay to blow away the defaulted 
> > acl and replace it with an inherited one descending from above.
> 
> is there any more information available on this proposed flag? It's 
> not clear to me that SE_DACL_DEFAULTED applies to file system objects 
> at all under Windows; it could also be an Active Directory only thing 
> from my reading of MS docs.

Just googling around....  From

http://technet2.microsoft.com/WindowsServer/en/library/9c7bc921-2517-4e7
a-ba39-d37c8b8202e31033.mspx?mfr=true

it does look like DEFAULTED is set in the case above.  But the real test
would be for someone to actually experiment with a Windows system.

In NFSv4 there are two possible sources that determine the ACL on a new
object: the ACL (and/or mode) attributes sent with the OPEN or CREATE
call, and the inheritable ACLs on the parent.

In Windows there appear to be three:
	- inheritable ACLs on the parent
	- ACLs included with the create (actually with the security
	  descriptor included in the create)
	- a default ACL associated with a given "access token"; I don't
	  understand what that is, but it's apparently some
	  representation of the user.

The DEFAULTED flag is set in the third case, and only when the first two
are absent.  Since we don't this default-ACL-for-a-user notion in NFSv4,
I don't believe we can take advantage of the DEFAULTED flag.

--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: Sat, 11 Nov 2006 20:33:31 -0500

> contain mode bits and not an acl, right?

I consider mode bits to be mostly a special case of ACLs.  So the
interesting question is what to do when a server gets an open or create
request that doesn't set *any* permissions (mode or ACL).

It won't get such a request from a unix application, because they always
set mode bits on create.  So the only reason I can see to specify
behavior in this case is to ensure that server behavior meets the
requirements of Windows applications.

>From the one tiny bit of documentation I read yesterday, it appears that
servers may, in this case, fall back on a default ACL found in something
called an access token.  I don't know what a Windows "access token" is.
If we're going to require that servers do this, then we're going to have
to explain what an acess token is and how the server finds out about it.
This all sounds like a lot of trouble to me.  If someone else wants to
figure it out and propose it, ok.

Till someone does that, I believe we should continue to leave behavior
unspecified in the case of a create without mode or ACL.

> an OWNER@ ace with the inherit flags on the new dir?

This is also unspecified, and I'd rather leave it that way.

--b.

---

From: "J. Bruce Fields" <[email-masked]>
Date: Sat, 11 Nov 2006 20:54:26 -0500

> unspecified in the case of a create without mode or ACL.

(Sorry, I should have said "in the case of a create without mode, or
ACL, or inherited ACEs.")

--b.