Subject: Re: ACLs

From: Mike Eisler <[email-masked]>
Date: Wed, 11 Aug 1999 17:21:24 -0700 (PDT)

> Date: 29 Jul 1999 20:58:55 +0100
> From: "Carl Beame" <[email-masked]>
> Subject: ACLs
> To: [email-masked]

I didn't really have much to add to Dave Noveck's comments, other
than that some bits need to be described. Sorry I didn't get this out
sooner, especially a response to Boris' question. I look forward to
the next iteration of this.

> const ACL4_ALLOW_DENY = 0x00010000;

What is ACL4_ALLOW_DENY for? I didn't see it described.

> const GENERIC_READ    = 0x80000000;
> const GENERIC_WRITE   = 0x40000000;
> const GENERIC_EXECUTE = 0x20000000;
> const GENERIC_ALL     = 0x10000000;

Could GENERIC_ALL be the OR of the previous 3?

> const FILE_READ_DATA        =   0x0001;     // file & pipe
...
> const FILE_ALL_ACCESS = (0x000F0000 | SYNCHRONIZE | 0x1FF);

The above (deleted the ones in between for brevity) need a description too.

Comments in response to other responses:

=============================================================
Noveck, Dave ([email-masked]) wrote on Thu, 29 Jul 1999 14:03:35 -0700:

> > There are several special identifiers which need to be 
> > understood 
> > universally. They are as follows:
> > 
> > "OWNER@" - The owner of the file.
> > "GROUP@" - The group associated with the file.
> > "EVERYONE@" - The world.
> 
> We might take advantage of Unicode reserved areas to define
> something that was even less likely to conflict with other
> uses.

If the areas are reserved, doesn't it mean that a lowly IETF WG
shouldn't use them?

We could minimize risk of conflict by suffixing them with something like:
	"nfsacl.ietf.org"

> > "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.
> 
> For many of these it is unclear how the information in question
> could be passed to the nfs server (e.g. whether the accessor is
> a batch job or a system service) so there is no way that the nfs
> server could act on these entries. 

Carl pretty much covered this, but I'll add that in addition to
NETWORK, an NFS server should be able to discern NETWORK, ANONYMOUS,
and AUTHENTICATED (I'm assuming a principal might match more than one
special identifier). In some cases, it will be able to discern SERVICE.
This is possible if the client is using RPCSEC_GSS, and the GSS-API
name type of the principal is the host ype, which is of canonical for
service_name@host.

> > Translation from ACL4_METHOD_POSIX to ACL4_METHOD_ORDER 
> > is possible, but
> > converting in the other direction is not one to one. (no 
> > solution yet).
> 
> What to you mean "yet"? I think is a problem that will never have
> a solution. The space of ORDER ACL's (with denial entries) is just
> bigger. 

I agree. Defer to the NT way on this. The UNIX world had its shot at
standardizing ACLs and blew it. I think customers will be more interested in
NT ACL semantics than UNIX ACL semantics, since there is no standard for the
latter. Existing proprietary UNIX ACL protocols could be accomodated as named
atrributues ("sub files") within the protocol, and trapped by the NFS clients
and servers that use them.

=============================================================
Boris Z. ([email-masked]) wrote on Fri, 30 Jul 1999 14:38:32 -0400 :

> However, having this and the current ACCESS semantics, 
> how can we answer following questions:
> 
> - Am I (== Kerberos authenticated subject) an owner of the file?

Unless I'm missing something ...

The client will need to map the application's operating system
dependent user id to the utf8 string uid. Once htis mapping is done,
a GETATTR on the file to get the owner will permit a string
comparision.

If the application wants this information, then it is likely not going
to be dealing with NFS V4 utf8 identifier strings. The operating system needs
to map the strings oeprating specific identifiers, 32 bit uids and gids
in the case of UNIX, something else on other platforms.

Whether the subject is Kerberos authentication or authenticated with
another security scheme isn't really the issue.

> - Can I change (set myself as) the owner of the file?

I take it there is a need for this on Wintel platforms. If so,
would extending ACCESS to support a bit which asks "does the caller
have rights to set ownership on file" suffice?

> - How can I get a list of acceptable 'who-s' (owner and groups) to use in
> PUTACL?

The application specifies a list of 'who-s' when it invokes the
operating systems sefact() API, and the NFS file system translates each
'who' to an NFS V4 string identifer.

=============================================================
Carl Beame ([email-masked]) wrote on 31 Jul 1999 16:09:34 +0100:

>> I'm thinking that nfsacl4 would be defined as ace4<> and that 
>> the nextentry field could not be needed.

> I would then suggest an ACE_COUNT field.

But if it's a variable length array, the rpc code generator (e.g. rpcgen)
will produce C structs that have a length field counting the number
of entries in the array.

	-mre

---

From: Carl Beame <[email-masked]>
Date: 12 Aug 1999 16:49:11 +0100

> What is ACL4_ALLOW_DENY for? I didn't see it described.

Actually I described it in a further email. It is just an indication
to the client that the server does support the DENY type of ACE. Many
Unix systems don't allow DENY ACEs and thus would not set the flag.

> Could GENERIC_ALL be the OR of the previous 3?
Under NT having WRITE access does not imply DELETE access. Therefore
having GENERIC_READ|GENERIC_WRITE|GENERIC_EXECUTE access to a file
does not allow for DELETE access.

- Carl

P.S: There are more need defining, but I think I need to do some
checking before answering.