Subject: RE: Update to ACL processing description

From: "Yoder, Alan" <[email-masked]>
Date: Tue, 2 Nov 1999 14:54:10 -0800

> >    I also am wondering (perhaps a bit late), whether the permissions
> > bits are supposed to allow servers to emulate AFS ACLs?  It looks to
> > me like "rlwida" are covered, though some suitable #defines to specify
> > the necessary combinations would perhaps be welcome.  I can suggest
> > those if it is wanted.  What about "k", though?  Is "SYNCHRONIZE"
> > supposed to cover that?  How about the eight programmatically definable
> > masks "A" through "H"?  Should we include placeholders for those?
> 
> This begs a fair question. It is also a difficult question. Should
> NFSv4 define a file model? Should it accomodate a variety of file
> models? The problem is that the ACL model drags in a lot of other
> non-file stuff, like SID vs UID/GID. I tend to approach such questions
                       ^^^^^^^^^^^^^^
   Isn't this taken care of by having "who" be in UTF-8?

> in terms of commercial viability. Does AFS matter? Does NT matter (duh)?
> I don't know a compelling answer. I just wanted to frame the question.

   So far, in looking at it, AFS support looks to be very cheap, so
long as we have an extra 8 bits in the mask to burn for the "A" through
"H" permissions.  Those are not interpreted by the server, according to
http://www.transarc.com/Library/documentation/afs/3.5/unix/user/user10.htm#H
DRWQ48.

   I don't pretend to know the answer to "does AFS matter?".  But it 
seems at first blush that if it does, DCE and Solaris/POSIX ACLs 
ought to be given consideration as well.  Sooooo.....
   The only thing in the Solaris "setfacl" man page that isn't already 
covered in Carl's spec is the "who" == "mask" part, AFAICT.  That seems
to map pretty directly onto setting an ACE with ACE4_INHERIT_ONLY_ACE and
ACE4_FILE_INHERIT_ACE set.  But we could use some language to that effect,
I guess.  
   Briefly looking over the DCE stuff, I see a number of "ACE who"s that
would
need to be added somehow or other.  E.g. FOREIGN_AUTHENTICATED,
FOREIGN_GROUP,
USER_DELEGATE, etc.  More info:
 
http://www.transarc.com/Library/documentation/dce/1.1/admin_gd_core_6.html#6
.2.
This makes me a lot more nervous, especially the delegate part.  It means
adding 
a whole bunch of additional special-case semantic functionality into the
server, 
doesn't it?

   I think it's worth thinking about trying to come up with a comprehensive
model, within reason of course.  The main impact is when people are trying
to
move from one filesystem to another.  We have some experience with that at
NetApp, and not to belabor the obvious, it sure is a lot easier when there
is an information-preserving mapping between the two permissions models.

   Carl, I do notice that there is no ADMINISTRATORS or ROOT entry in
section
5.7.4, "ACE who".  How is root access provided for?  What about NT's
somewhat 
baroque way of providing root access through TakeOwnership followed by some
other
operation?

Alan

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

---

From: Carl Beame <[email-masked]>
Date: 03 Nov 1999 11:50:06 +0000

On Tue Nov 02 22:54:10 1999, Yoder, Alan wrote:
> baroque way of providing root access through TakeOwnership followed by
> some other operation?
> 

The NT ADMINISTRATORS when dealing with Files is no different then any
other GROUP under NT. There does not need to be any special change to
the spec to handle it. 

root access is something which is NOT defined under NFS. NT has a
privilege called "Take Ownership". The name of this privilege is
incorrect. The privilege actually gives you permission to change the
ownership of the file to any user. The MKS toolkit comes with a chown
program which allows you to do this.

If you define root access as the ability to bypass file permission
checking, then NT supports this with the privilege "Backup Files and
Directories". This is just like VMSes BYPASS privilege.

Our current NFS NT server, allows root access the same way Unix
does. This is strictly an implementation issue and not one which is
handled by ACLs. .... unless of course you want to introduce an
identifier "ROOT@" which means "A user which normally can bypass
permissions but can't bypass this one!!!" :-).

- Carl