Subject: RE: ACLs

From: "Yoder, Alan" <[email-masked]>
Date: Thu, 21 Oct 1999 16:46:20 -0700

> struct nfsace4 {
> 	acetype4 type;
> 	aceflag4 flag;
> 	acemask4 access_mask;
> 	utf8 who;
> };
> 
> Each nfsace4 entry is assumed to be processed in order by the 
> server. The first Access
> Control Entry is used where both the "who" and the 
> "access_mask" match the requester and the 
> type of access desired. Any later additional Access Control 
> Entries which also match are
> ignored.

   Are you intentionally deviating from the NT model here, Carl?
Under NT, I believe you keep reading ACEs until the rights comprising 
the desired access mask have all been accumulated, or any one of them
specifically denied. 

> ACE4_FILE_INHERIT_ACE   ...
> ACE4_DIRECTORY_INHERIT_ACE   ...
> ACE4_INHERIT_ONLY_ACE   ...
> ACE4_NO_PROPAGATE_INHERIT_ACE can be placed on a directory. Normally 
> 	when a new directory is created and an ACE exists on the parent 
> 	directory which is marked ACL4_DIRECTORY_INHERIT_ACE, two ACEs 
                                ^^^^  --> ACE4 ?
> 	are placed on the new directory. One for the directory itself and
> 	one which is an inheritable ACE for newly created directories.
> 	This flag tells the O/S to not place an ACE on the newly created
>     directory which is inheritable by subdirectories of the created
directory.

   So this is a non-recursive ACE for new directories in the directory?
I'm having difficulty thinking of a use for this compelling enough to
justify the brain cramp.  I see that it's there in NT; does anyone ever 
use it?  I asked a couple other CIFS developers here about it, and Mark
pointed out that it's not even exposed in the GUI.
   Also, what rules apply when two conflicting flags are both set, e.g.
ACE4_DIRECTORY_INHERIT_ACE and ACE4_NO_PROPAGATE_INHERIT_ACE?

> ACE4_SUCCESSFUL_ACCESS_ACE_FLAG and 
> ACL4_FAILED_ACCESS_ACE_FLAG indicate for 
> 	AUDIT and ALARM which state to log the event.
> 	On every ACCESS or OPEN call which occurs on a file or directory
> 	which has an ACL that is of type ACE4_SYSTEM_AUDIT_ACE_TYPE or
> 	ACE4_SYSTEM_ALARM_ACE_TYPE, the attempted access is compared to the
> 	ace4mask of these ACLs. If the access is a subset of ace4mask 
> 	and the identifier match, an AUDIT trail or an ALARM is generated. 
> 	By default this happens regardless of the success or failure of the
> 	ACCESS or OPEN call.   
> 
> 	The flag ACE4_SUCCESSFUL_ACCESS_ACE_FLAG only produces the AUDIT or
> 	ALARM if the ACCESS or OPEN call is successful. The
> 	ACE4_FAILED_ACCESS_ACE_FLAG causes the ALARM or AUDIT if the ACCESS
or
> 	OPEN call fails.

   Under NT, these kind of events get stuffed into the event
logging/forwarding 
apparatus.  What is the proposed mechanism here?  Sorry if it's already been
specified 
and I just missed it.

> ACE4_IDENTIFIER_GROUP indicates that the "who" refers to a 
> GROUP as defined under Unix.
> 
> ****** Area for Discussion *****************
> 	If a client or server does not have the concept of 
> GROUP, it SHOULD (a) ignore	this flag and treat to "who" as best it can,
or (b) 
> return an error ????

   The only reason to distinguish between users and groups at the ACL level,
that I can see, is because there might be a user and a group with the same
name.  If there's no concept of a group, and user names are unique, then 
there can't be any conflicts.  What am I missing? 

> "OWNER" - The owner of the file.
> "GROUP" - The group associated with the file.
> "EVERYONE" - The world.
> "INTERACTIVE" - Accessed from an interactive terminal.
> "NETWORK"- Accessed via the network.
> "DIALUP" - Accessed as a dialup user to the server.
> "BATCH" - Accessed from a batch job.
> "ANONYMOUS" - Accessed without any authentication.
> "AUTHENTICATED" - Any authenticated user (opposite of ANONYMOUS)
> "SERVICE" - Access from a system service.
> 
> To avoid conflict these special identifiers should be of the 
> form "xxxx@".
        ^^^^^
   xxx@yyyy ?

Alan

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

---

From: Carl Beame <[email-masked]>
Date: 22 Oct 1999 01:31:36 +0100

> the desired access mask have all been accumulated, or any one of them
No. My mistake, I will reword this in the next iteration ... it takes
a bit of explaining.
> > 	directory which is marked ACL4_DIRECTORY_INHERIT_ACE, two ACEs 
Typo.
> pointed out that it's not even exposed in the GUI.

We could drop it, but if and when it is exposed will we need to add
it? Note that there are several flags which were NOT exposed in the NT
4.x GUI but are now exposed in the NT 2000 GUI.

> ACE4_DIRECTORY_INHERIT_ACE and ACE4_NO_PROPAGATE_INHERIT_ACE?

These are NOT in conflict. 
> apparatus.  What is the proposed mechanism here?  Sorry if it's

There is no proposed mechanism as each OS will do a different thing.
There is no need in the NFS V4 specification to define how each OS
logs or alarms events.

> > To avoid conflict these special identifiers should be of the 
 No "xxxxx@", ie. "OWNER@", "GROUP@", "EVERYONE@" ...

- Carl

---

From: Mike Eisler <[email-masked]>
Date: Thu, 21 Oct 1999 22:10:35 -0700 (PDT)

> there can't be any conflicts.  What am I missing? 

What if the server supports a concept of separate group and user name spaces,
and the client doesn't? Then the user name space and gid name space collide.
Won't that impact the set of clients (Windows/NT) that don't support the
concept of separate name spaces?

Carl wrote:

> I personally would suggest that if the server can itself 
> 	determine if an identifier is a group it should ignore this flag on a
> SETATTR
> 	request and return it on a GETATTR request.

I agree.

	-mre

---

From: Gordon Waidhofer <[email-masked]>
Date: Fri, 22 Oct 1999 00:00:49 -0700

> No. My mistake, I will reword this in the next iteration ... it takes

ACCESS_MAX is special. Also, GENERIC_READ, GENERIC_WRITE, etc, which
pair reasonably well to UNIX modes, must be interpretted at run-time.

> 4.x GUI but are now exposed in the NT 2000 GUI.

The NT 4.x GUI does not expose it, per-se. It does use it.

>  No "xxxxx@", ie. "OWNER@", "GROUP@", "EVERYONE@" ...

The null domain as a wildcard seems OK. I might suggest * (star).

NT Tokens (much like UNIX credentials) do not include
well known groups like Everyone as part of the user's
memberships. They only appear in ACEs. These IDs are
truly well known. There are some semi-goofy IDs,
also not explicitly given as memberships, like:

	DOMAIN_USERS	*@mydomain
	DOMAIN_ADMINS	almost-*@mydomain

Then there are really goofy IDs

	CREATOR_OWNER	only interpretted for inheritance
	CREATOR_GROUP	ditto

-- 
==================================================================
  Gordon W Waidhofer                    Traakan Software, Inc.
  [email-masked]                       111 Main St., Suite #5
  650-947-1583  Direct                  Los Altos, CA  94042
  650-947-1580  Main                    http://www.traakan.com
  650-947-1588  Fax

---

From: Carl Beame <[email-masked]>
Date: 22 Oct 1999 18:40:32 +0100

> pair reasonably well to UNIX modes, must be interpretted at run-time.
As far as I understand ACCESS_MAX, GENERIC_READ, GENERIC_WRITE (for
Unix readers these refer to NT attributes, NOT the values I have in
the ACL proposal), are used to tell the security system that the user
is granted generic access to an object AS DEFINED BY THE OBJECT.

The best way to describe this is to give an example. Suppose an object
was simply a range of virtual memory. The only specific rights that
would be applicable to this object are ACE4_READ_DATA and
ACE4_WRITE_DATA. If the user attempted to set the right
ACE4_READ_STREAMS, NT would return an error as there are no additional
streams on a piece of memory. To make things simple, NT has
GENERIC_READ/WRITE attributes which can be placed on any object. NFS
V4 ONLY deals with file objects and thus we can defined GENERIC_READ
to be the mask of all the specific attributes associated with files.

For NT Server writers you would probably compare the incoming
ace4mask to the define GENERIC_READ/WRITE (as defined in NFS V4) and
if they match, use the NT GENERIC_READ/WRITE attribute instead.

> 	DOMAIN_ADMINS	almost-*@mydomain

Actually DOMAIN_USERS and DOMAIN_ADMINS are considered a Group under
NT and not "well known permissions", so they should not be in this
list. 

> 	CREATOR_OWNER	only interpretted for inheritance
I simplified their names to OWNER and GROUP and they are included.

- Carl