Subject: RE: ACLs: clarification of requirements

From: "Noveck, Dave" <[email-masked]>
Date: Wed, 29 Aug 2001 13:20:35 -0700

Mike Kupfer wrote: 
> >>>>> "Carl" == Carl Beame <[email-masked]> writes:
> 
>     Carl> On Sat Aug 25 01:23:26 2001, Mike Kupfer wrote:
> 
>     >> Now the impression I get from reviewing my mail archives is
>     >> that this approach is NOT endorsed by the working group.
>     >> Instead, the working group expects that if an implementation
>     >> says it supports v4 ACLs, then it supports them completely: all
>     >> the different access masks are fully supported, all the
>     >> different flags are fully supported, and all the different
>     >> types (ALLOW, DENY, AUDIT, ALARM) are fully supported.
>     >>
>     >> Question 1: does this match everyone else's understanding?
> 
>     Carl> That was not my understanding when I first started listing
>     Carl> the flags.
> 
> Okay.  Anyone else want to comment?
> 
> My personal opinion is that the implementation should be allowed to do
> a best-effort simulation of the different masks, flags, and types, but
> I haven't been seeing much agreement with that position, even within
> Sun.

I don't think it is a good idea to require that the server completely
implement every option.  However I'm a little leery of writing a 
blank check that covers anything that can described as "best effort".

Can we define a set of rules such that if clients obey them and keep
to that subset, servers should always accept and act on their ACL's?

> Does anyone have any statistics on how often NT users create ACLs that
> could not be easily mapped to a POSIX model (e.g., APPEND_DATA is
> allowed but WRITE_DATA is not)?  My understanding of the AFS
> experience is that users tend not to create complicated ACLs.

I certainly don't have any statistics.

Things that might prevent a mapping to the posix model:

     Order-dependency and deny-type elements.

     Alarm and audit types.

     Bits maps that are finer than what V4 distinguishes for ACCESS.

So my feelings about those are:

     Order-dependency and deny is fundamental to the ACL model and
     we should not force clients to essentially have POSIX ACL's.

     alarm and audit should be optional features which servers may
     reject.

     It is very reasonable for a V4-server to not support acl access
     bits that are finer than the V4 protocol can really distinguish.
     Basically, the rest of V4 can only distinguish the modes of access
     returned by ACCESS.  For evrything else there is really no 
     definition of how V4 operations map into those finer bits.
     So I think we need to map each of those acl bits to one of the
     access bits.  Ace's that specify identical handling for all
     the acl bits that correspond to a single ACCESS bit are portable
     and should have a predictable result.  Where acls have non-portable
     ace's the server may reject them or store them and use them 
     with the understanding that which ace bit is checked for a
     given operation is not specified by the protocol and may be
     server-dependent (and the information is available for local
     use or use by other protocols that do distinguish these bits).

>     >> What if the server doesn't distinguish--for example--batch
>     >> access, and an NFS client tries to create an ACE with
>     >> who="BATCH@"?  Are there any requirements on what the server
>     >> does with such a request?  Should there be?

>     Carl> I don't think there are requirements, but should it just
>     Carl> store the ACE so as not to loose information from the ACE if
>     Carl> it is a file copy? Also if who="NETWORK@" and NFS can be
>     Carl> "made" to honour the ACE, but Samba can't, should it be
>     Carl> stored???

An NFS-V4 server can't distinguish batch access from non-batch access
under any cirsumstances.  There is nothing in the protocol to allow
this information to be passed from client to server.  I suppose
the reason for that is that it is normally not very interesting,
especially since, in a security-related context, if you are going
to accept the client's word for it, it is worthless (as opposed to
the clients authenticated identity which is worth something).  So
this raises (at a high volume) the question: "Why do we have this
in our ACL's?"  Is this something we have gotten from NT?

> Good question(s).  I think the key decision is whether it's better to
> store an ACE but not enforce it, versus refusing to store the ACE even
> though somebody else might be able to enforce it.  

> The problem with "storing but not enforcing" is that a user might look
> at the ACE and conclude that the file is more secure than it really
> is.

You could implement things to use conservative enforcement.  So to use
the batch example, a V4 server would never recognize batch use in an
ALLOW entry because it doesn't know that the access is from a batch job 
(however that is defined), but would always recognize batch use in a
deny entry because it doesn't know that access isn't from a batch job.

> I guess I lean towards leaving it up to the implementation, but
> discussing the issues somewhere in the RFC.

I think clients need a subset that they can use with some assurance.
For stuff that is outside it, I think leaving it up to the implementation
and discussing the issues in the RFC, as you describe, is the right
strategy.

---

From: Mike Kupfer <[email-masked]>
Date: Fri, 31 Aug 2001 14:17:02 -0700

>>>>> "Dave" == Noveck, Dave <[email-masked]> writes:

    Dave> An NFS-V4 server can't distinguish batch access from
    Dave> non-batch access under any cirsumstances.  
...
    Dave> So this raises (at a high volume) the question: "Why do we
    Dave> have this in our ACL's?"  Is this something we have gotten
    Dave> from NT?

If I remember correctly, we asked Carl to post a writeup of what NT
does for ACLs, and then we took that as the v4 ACL spec, without much
further revision.

    Dave> I think clients need a subset that they can use with some
    Dave> assurance.  For stuff that is outside it, I think leaving it
    Dave> up to the implementation and discussing the issues in the
    Dave> RFC, as you describe, is the right strategy.

What you say makes sense (both what I quoted, and in the rest of your
mail).  I'm willing to propose changes based on what you wrote, though
it may take me a couple weeks to come up with something worth
posting.  Of course, if someone else wants to take this on, I'd be
happy to stand back and let them go for it. :-)

mike

---

From: Brent <[email-masked]>
Date: Fri, 31 Aug 2001 14:51:20 -0700

> in our ACL's?"  Is this something we have gotten from NT?

There's a similar situation with the "execute" bit in the 
file permission bits of NFS v2/v3.

The client uses it as a tag to distinguish executable files
from non-executable, though the server doesn't "enforce"
the bit, e.g. if you create a file with perms

	--x--x--x  (0111)

then the client will prevent a local process from reading it,
but the server cannot prevent an NFS client from reading
the file.

The server should not attempt to store an NFSv4 ACL if
it cannot accurately map the ACL to its local equivalent,
e.g. POSIX or permbits.  Better that it return an INVAL
or NOTSUPP error.

Similarly, Win2000 clients will have to be conservative
in their expectations of v4 ACLs. Other than NTFS, most
filesystems will be incapable of storing a the gamut of
NFSv4 ACLs.  

	Brent