Subject: v4 Archives page unavailable in playground.sun.com

From: Stevan Steve Allen <[email-masked]>
Date: Tue, 25 Feb 2003 07:43:59 -0800

Following page does not come up.  Server problem?

http://playground.sun.com/pub/nfsv4/nfsv4-wg-archive/

Thanks,
Stevan C. Allen

---

From: Robert Thurlow <[email-masked]>
Date: Tue, 25 Feb 2003 10:20:16 -0700 (MST)

> http://playground.sun.com/pub/nfsv4/nfsv4-wg-archive/

Yes - it's being worked, but I can't promise quick resolution :-(

Rob T

---

From: "Sergey Klyushin" <[email-masked]>
Date: Thu, 27 Feb 2003 19:20:07 -0800

We had a long discussion with Carl Beam about ACL in NFSv4 and finally 
decided to post the resume of our discussion here. (Carl, please add or 
correct me if I missed something)

First of all I do realize that now is very bad time to change NFSv4 
protocol. I hope that ACL issues could be resolved in NFSv4.1 or partially 
in NFSv4.0 without changing .x part or with a minimum changes (adding 
defines).

Secondly, hopefully there are not much implementations of NFSv4 ACL.
(Dave, I'll buy you a drink if you would agree to change your Server)

Thirdly, sorry for a long email and please try to read till the end.

I. Synchronization of ACL and mode.

================ from protocol ====================================
5.11.6.  Mode and ACL Attribute

   The server that supports both mode and ACL must take care to
   synchronize the MODE4_*USR, MODE4_*GRP, and MODE4_*OTH bits with the
   ACEs which have respective who fields of "OWNER@", "GROUP@", and
   "EVERYONE@" so that the client can see semantically equivalent access
   permissions exist whether the client asks for owner, owner_group and
   mode attributes, or for just the ACL.

   Because the mode attribute includes bits (e.g. MODE4_SVTX) that have
   nothing to do with ACL semantics, it is permitted for clients to
   specify both the ACL attribute and mode in the same SETATTR
   operation. However, because there is no prescribed order for
   processing the attributes in a SETATTR, the client must ensure that
   ACL attribute, if specified without mode, would produce the desired
   mode bits, and conversely, the mode attribute if specified without
   ACL, would produce the desired "OWNER@", "GROUP@", and "EVERYONE@"
   ACEs.
====================== end ====================================

Why mode MUST be synchronized with ACL? Does any OS do it? Windows does not.

I consider synchronization of mode and ACL as a biggest issue of ACL in
NFSv4.

mode bits are too narrow to define access and are really only used for an
approximation on an LS command. The ACCESS procedure is the only true way of

determining if a file is accessable.
 
Since NFSv3 we have ACCESS procedure that answer the question about access
permissions. In real life access permissions may be based on much more 
conditions than mode and ACL. For example, if user account is disabled on 
Windows OS, than user can't do anything with a file even though user has 
full access rights.

Requiring synchronization as MUST (even as low case must), just makes much 
more headache for both Client and Server, but doesn't guarantee real access 
rights.

If client wants to estimate access rights, client always may ask for mode 
and for ACL and combine them together. The rules how to estimate access
rights from mode and ACL may be specified if needed.

Moreover, NFSv4 protocol says:
==========================================================
   Although, the client can read and write the ACL attribute,
   the NFSv4 model is the server does all access control based on the
   server's interpretation of the ACL.  If at any point the client wants
   to check access without issuing an operation that modifies or reads
   data or metadata, the client can use the OPEN and ACCESS operations
   to do so.
==========================================================

I believe that synchronization requirement has to be removed from protocol.

II. Special "who" names OWNER@/GROUP@

The original idea of special identifiers OWNER@ and GROUP@ is quite 
different from what we have in protocol now. Originally OWNER@/GROUP@ came 
from Windows's CREATOR_OWNER/CREATOR_GROUP which is defined as following:

Creator Owner ID - A security identifier to be replaced by the security 
identifier of the user who created a new object. This SID is used in 
inheritable ACEs. 
Creator Group ID - Identifies a security identifier to be replaced by the 
primary-group SID of the user who created a new object. Use this SID in 
inheritable ACEs. 

So, CREATOR_OWNER/CREATOR_GROUP ACE

1. can be set on directories only (not on files) 
2. MUST be set with INHERIT_ONLY flag.
3. is a placeholder ACE whose "who" field will be replaced by real 
owner/group name on newly created files/directories.
 
However, now OWNER@/GROUP@ ACEs are very tied to mode synchronization and 
used in addition to ACEs of real owner/group:

============================================================
5.11.4.  ACE who

   There are several special identifiers ("who") which need to be
   understood universally, rather than in the context of a particular
   DNS domain. 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, even if none of the access methods
   on the server understands the identifiers.

   Who                    Description
   _______________________________________________________________
   "OWNER"                The owner of the file.
   "GROUP"                The group associated with the file.
==============================================================

There is also requirement of mapping mode to/from OWNER@/GROUP@/Everyone@ 
ACEs. So, looks like NFSv4 uses OWNER@/GROUP@ ACEs ONLY for mapping mode 
into ACL. According to protocol Client and Server must always add 
OWNER@/GROUP@ ACEs to ACL in addition to ACE of REAL owner/group.
(see above about synchronization)

Let's look further. Protocol defines 
====================================================
  ACE4_IDENTIFIER_GROUP

   Indicates that the "who" refers to a GROUP as defined under UNIX.
====================================================

If we do need ACE4_IDENTIFIER_GROUP, then ACE4_IDENTIFIER_OWNER should be
also defined. Is there are reason why ACE4_IDENTIFIER_OWNER not defined in 
protocol? 

The questions are: 
1. Why do we need OWNER@/GROUP@ ACE in ADDITION to ACE[s] of real
owner/group? 
2. Do we need them for synchronization ONLY?
3. Is it possible to change wording in NFSv4 protocol to use OWNER@/GROUP@
ACE[s] in Windows manner like CREATOR_OWNER/CREATOR_GROUP?

III. chown/chgrp implementation

Special care should be taken in implementation of chown/chgrp.
The basic ideas are
1. new owner/group will get the same access rights as old one (or more???).
2. Consider the following example:
2.1 Owner of the file is Test_User_1
2.2 There is Test_User_2 ACE with full permissions.
2.3 Test_User_2 becomes an owner.
2.4 Test_User_3 becomes an owner.
2.5 Test_User_2 MUST NOT loose access rights he had before becoming an 
owner. 

IV. more special ACE names

Section " 5.11.4. ACE who" describes processing of special identifiers 
("who") and provides list of such ACEs. However, this list already missed
some "special" Windows names like "NETWORK SERVICE", "REMOTE INTERACTIVE
LOGON", etc. I am almost sure there are more "special" names on another OSs.

Like all things we (the NFS community) need to have some list somewhere that

is controlled that implementers can add well defined names to. 

Why not to add to "5.11.4. ACE who" something like this:

"The list of special identifiers ("who") is not restricted to the list 
specified here. If "who" name is constructed in the form "xxx@", the name
MUST be considered as special identifier. The meaning of special identifiers
not listed in the protocol could be checked at [some place]."

The same rules MUST apply to name of owner and owner_group.

V. Definition of EVERYONE@

Protocol defines EVERYONE@ as "The world", so EVERYONE@ includes owner and
group. However, in another places protocol discusses mapping of MODE4_*OTH
to "EVERYONE@" ACE. The protocol should state more clearly, that EVERYONE 
can't be DIRECTLY mapped to MODE4_*OTH.
For example, if mode is "------rwx", then creating ACL with only one ACE of
EVERYONE will give different access permissions for owner and group. So, ACL
should have DENY ACEs of owner and group that precedes EVERYONE ACE.

Once again, if we remove mode and ACL synchronization requirement, then this
problem won't exist.

Should we specify that "The world" includes owner and group?

VI. ACE4_INHERIT_ONLY_ACE and ACE4_NO_PROPAGATE_INHERIT_ACE

ACE4_INHERIT_ONLY_ACE and ACE4_NO_PROPAGATE_INHERIT_ACE flags can't be used 
alone without ACE4_DIRECTORY_INHERIT_ACE and/or ACE4_FILE_INHERIT_ACE flags?

It's not clear what error to return in this case. INVAL? ATTRNOTSUPP?

VII. NULL and empty ACL

Windows OS supports empty and NULL ACLs, however meaning of empty ACL (no 
access to anybody) is totally different from NULL ACL (full access to 
Everyone). Is there any other OS that distinguishes NULL and empty ACL?

Should it be added to protocol?
There is no way for NFS Server to report that there is no ACL (==NULL) set
on the file.

VIII. Clarification of ACL processing.
From protocol
========================================================================
   To determine if a request succeeds, each nfsace4 entry is processed
   in order by the server.  Only ACEs which have a "who" that matches
   the requester are considered.
......
   When the ACL is fully processed, if there are bits in
   requester's mask that have not been considered whether the server
   allows or denies the access is undefined.  If there is a mode
   attribute on the file, then this cannot happen, since the mode's
   MODE4_*OTH bits will map to EVERYONE@ ACEs that unambiguously specify
   the requester's access.
========================================================================
This part requires clarification.
(1. BTW, this is another place where protocol implies synchronization 
between mode and ACL.)
2. When it says matches it implies that match is based on the definition of
the ACE type and not only "Only ACEs which have a "who" that matches the 
requester are considered".
For example the BATCH ACE type matches any task which is batch vs
interactive. Thus user1 (if he is owner of the file) matches OWNER@ and 
OWNER@ ACE should be considered.
3. If synchronization is required, than description should be changed to
consider not only EVERYONE@ ACE, but OWNER@ and GROUP@ ACEs also.
4. Consider the following example:
- test_user_1 is an owner of the file
- test_user_1 is member of test_group_1
If there are test_user_1, test_group_1, OWNER@, GROUP@, EVERYONE@ ACEs set 
on the file, than test_user_1 access permissions will be based on all these 
ACEs.

5. Why access is not defined if there is no mode? 
It should be defined that
When the ACL is fully processed, if there are bits in requester's mask that 
have not been considered, than
- Server will not allow (*NOT DENY*) access at the end of ACL processing.
- If access is DENIED at the end of ACL processing, Server returns error
- Server may use other sources for access checking (like mode, user's 
privileges) and apply them if access is not allowed (BUT NOT DENIED) at the 
end of ACL processing.
- If there are no such additional sources for access checking, then Server 
returns error.

Note, there is no synchronization requirements needed here, because anyway
it's approximation of user's access rights and still only one ACCESS
procedure (OK two - OPEN also) will tell Client the truth.

Special description should be added for NULL ACL (no ACL at all).

IX. Dealing with inheritable ACEs

Protocol says
======================================
   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 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 server to not place
   an ACE on the newly created directory which is inheritable by
   subdirectories of the created directory.
======================================
"Normally" creating two ACEs is implementation depended.

Two ACEs are created unless the NO_PROPAGATE is set. This is so that the 
user can change the access permitted in the ACE which refers to the newly 
created directory without changing the default inheritable access.
In this scenario ACE without INHERIT flag should precede ACE with 
INHERIT flag, because both of them are effective ACEs or 
all ACEs with INHERIT flag should have INHERIT_ONLY_ACE flag also.

Second scenario does not add second ACE. In this case user always may add 
explicit ACE to a directory if he wants to change default inheritable access

and keep inheritable ACE in place. 

X. Automatic propagation of inheritable ACEs.

This question was brought to mailing list attention some time ago (I guess 
by Eric), but was not completely solved.

This is most complicated issue and probably could be postponed until 
version 4.1. Actually there are not much changes required in .x file to
allow automatic propagation of inheritable ACEs, just a few defines. Most
complicated part is wording in ACL section.

Major problem is (at least for Windows):
Protocol says that ACE's with INHERIT_* flags will apply on NEWLY created 
objects ONLY. So, if ACL is changed on parent directory EXISTING child 
objects keep OLD ACL. 
Windows (default) inheritance works differently on Windows 2000/XP and could
be set to work the same way on NT4 with service pack 6a (latest NT supported

by Microsoft). Changing ACL on parent directory will automatically change
inherited ACEs in EXISTING child ACLs if child's ACL is not protected from 
such changes.

So, we've got deadlock here. Following NFSv4 semantic (don't change ACL of
existing child objects) will break Windows ACL approach.
Following Windows semantic (change ACL of existing child objects) will break
NFSv4 ACL approach.

Here is list of defines required for automatic propagation of inheritable 
ACEs:
ACL4_AUTO_INHERIT_REQ - Requests that the provider for the object protected 
by the security descriptor automatically propagate the ACL to existing child

objects.
ACL4_AUTO_INHERITED - ACL is set up to support automatic propagation of 
inheritable ACEs to existing child objects.
ACL4_PROTECTED - Prevents the ACL of the security descriptor from being 
modified by inheritable ACEs.
ACE4_INHERITED_ACE - Indicates that the ACE was inherited

That's all required changes for .x file to be able to implement automatic
propagation of inheritable ACEs.

Minor problem:
To add/remove one ACE from ACL NFSv4 requires full ACL update.
Two procedures are required to set/remove particular ACE from ACL.

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
That's all. 
If you read everything above this line, you are the hero.

Waiting for comments.
Sergey

---

From: "Gordon Waidhofer" <[email-masked]>
Date: Thu, 27 Feb 2003 22:19:16 -0800

Good post, Sergey. I'm looking forward to reading
a knowledgable response.

Here's two cents......

Some of the semantics about synchronizing mode and ACLs
come from the POSIX ACL design. It's an interesting
problem. For example, a Windows NFSv4 client talking
to a server with POSIX ACLs (Solaris) **MUST** meet
the OWNER@/ACL_USER_OBJ condition.

I see it as more necessary to maintain the OWNER@ and
GROUP@ special who identifiers than it being necessary
to have OWNER@ equivalent to CREATOR_OWNER. It came as
a bit of surprise the CREATOR_OWNER is only used for
inheritance in NT. I believe it, it's just a surprise.

Dave Noveck did a good presentation years ago about POSIX
ACLs v. NT ACLs. This presentation is well worth review
as NFSv4 ACLs are revisited.

  http://www.ietf.org/proceedings/99jul/slides/nfsv4-acl-99jul/

Among other tricky problems, Dave found differences in
POSIX ACL implementations. For example, a file
owner=fred mode=007 -- is fred denied access or granted
access? Some say denied, other say granted.
My reading of the POSIX ACL spec says that denied is the
official answer, but that also seem counterintuitive to me.
I concur that the right answer is ACCESS calls to the server.

NFS is most significant in UNIX land, and there is a
significant and growing presence of POSIX ACLs (Solaris,
Linux, *BSD, and many other recognizable flavors). POSIX
ACLs have the mode/ACL sync requirement. NFSv4 has no
choice but to take it quite seriously. It would be quite
wrong to cause POSIX ACLs a hardship because of NT, yet
it is also important to accomodate NT.

Here's about the only thing I do feel very strongly about.
NFSv4 ACL support is high on the list of benefits (over
NFSv3). It must be right. It must have consensus.
It must be done as part of 4.0, not 4.x. Flakey ACL
support in 4.0 (with a 4.x promise) would be detrimental
to NFSv4 acceptance and deployment.

Regards,
	-gww

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Sergey Klyushin
> Sent: Thursday, February 27, 2003 7:20 PM
> To: [email-masked]
> Cc: 'Carl Beame'; 'Noveck, Dave'; [email-masked]
> Subject: ACL in NFSv4 protocol
> 
>