Subject: ACLs: clarification of requirements

From: Mike Kupfer <[email-masked]>
Date: Fri, 24 Aug 2001 17:23:26 -0700

One of the issues that's come up with the Solaris v4 implementation is
ACL support.  One suggestion has been to do a best-effort simulation
of the v4 ACL model using Solaris's (draft) POSIX ACL implementation.
For example, the v4 access masks WRITE_DATA and APPEND_DATA would both
map to POSIX write permission.  This means you could not set
WRITE_DATA independent from APPEND_DATA: they would both be either on
or off.

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?

Question 2: what's the story on the special "who" values?  RFC 3010
says

   There are several special identifiers ("who") which need to be
   understood universally. Some of these identifiers cannot be
   understood when an NFS client accesses the server, but have meaning
   when a local process accesses the file. The ability to display and
   modify these permissions is permitted over NFS.

I assume that what this means is

  a. the server need not distinguish all the different access paths as
     listed in the RFC (e.g., batch versus interactive, or dialup
     versus network).

  b. if the server does recognize these different access paths, ACEs
     can be created using the corresponding special "who" values
     ("DIALUP@", "BATCH@", "INTERACTIVE@", etc.).

Anyone disagree?

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?

mike

---

From: Carl Beame <[email-masked]>
Date: 25 Aug 2001 12:24:45 +0100

> Question 1: does this match everyone else's understanding?

That was not my understanding when I first started listing the flags.

>      listed in the RFC (e.g., batch versus interactive, or dialup

True.

>      ("DIALUP@", "BATCH@", "INTERACTIVE@", etc.).
True.

> requirements on what the server does with such a request?  Should

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

- Carl

---

From: Mike Kupfer <[email-masked]>
Date: Wed, 29 Aug 2001 11:53:46 -0700

>>>>> "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.
    >>

    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.

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.

    >> 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???

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.

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

mike