Subject: Re: ACL in NFSv4 protocol

From: Mike Eisler <[email-masked]>
Date: Sat, 1 Mar 2003 23:07:43 -0800 (PST)

> From: "Sergey Klyushin" <[email-masked]>

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

Because we don't know what it means to have mode be in conflict
with the corresponding ACEs.

Since mode is a UNIX thing, I don't see how you can say Windows
does not. A Windows NFSv4 server should be able to derive mode from the
corresponding ACEs.

> 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

So it sounds like your server derives mode from the ACEs. That is
fine.

> 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 

Well the text came from Carl. :-)

If we need the name of the creator of the file (and a special name for
such an entity), then these are more attributes, and it are not going
to happen for NFSv4.0.

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

If ACE4_IDENTIFIER_GROUP is off, then the identifer refers
to a user, not a group, except for the case when the name
is one of the special ones (that have a trailing '@').

> The questions are: 
> 1. Why do we need OWNER@/GROUP@ ACE in ADDITION to ACE[s] of real
> owner/group? 

Ask Carl. :-)

We need them to identify the access rights for the 
owner and owner_group attributes (which contain the names
of thew file owner and group owner).

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

Not in v4.0.

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

Too late for NFSv4.0.

Regardless, I think the protocol, and not a implementation,
needs to define the semantrics of future special ids.

> 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

No, I don't think so.

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

This is my understanding.

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

Or if your server supports just one of mode and ACL,
this problem won't exist.

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

No, because it doesn't.

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

There doesn't seem any need for requiring an error, because
the effects are harmless. If for some reason our operating
environment produces an error, then ATTRNOTSUPP seems reasonable.

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

Why can't no access to anyone be a single ACE that denies
to everyone? (And if mode is support, the owner and group aces
that deny to the owner and group?).

> 5. Why access is not defined if there is no mode? 

Access is define by the ACL.

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

It's up to server implementation.

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

Not necessary, since mode is synchronized with ACL.

> - If there are no such additional sources for access checking, then Server 
> returns error.
> 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.

I don't think so. The text is just saying what happens
when _NO_PROPOGATE_ is set.

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

I think this is an implementation dependency. If the server's
local filesystem has this semantic (and in all likelyhood,
supports it efficiently ... I imagine the parent and
descendents each have points to a common ACL in the filesystem
metadata), then it supports it. Most UNIX systems won't
be able to support this semantic.

	-mre

---

From: Carl Beame <[email-masked]>
Date: 03 Mar 2003 09:48:51 +0000

Given the following what does "Synchronization" mean?

File: rwx------ (700) Owner Read/Write/Execute
on local system an ACL is added which contains one ACE:
	"FRED" - DENY WRITE

FRED is the owner of the file.

A local "ls" command will list the file as:
	rwx------

From an NFS connected machine, the mode will be?????

	r-x------ or rwx------ 

If Synchronized that I would assume you mean r-x------.

Now a CHOWN is done to CARL so what are the permissions on the file???

rwx------ with an ACE for FRED which denies him WRITE??

So the "Synchronized" ls changes the displayed mode to rwx------ from r-x------?

Is the above scenario different if the ACE is OWNER@ ???

-------------------------------------------------

I should note that my intention was the OWNER and GROUP were placeholders which
matched the current owner and current group, but were not "storable" values. The
real current owner and group would be inserted in the ACE before it went to
disk. By having them as "storable" values you can have two ACEs one which refers
to the OWNER of the file at any given time and the other refers to a specific
user who might now own the file. This was not the intention.

- Carl Beame

---

From: "Gordon Waidhofer" <[email-masked]>
Date: Mon, 3 Mar 2003 02:28:11 -0800

I believe for a POSIX ACL, the example would be:

	owner=fred					fred@foo
	ACL_USER_OBJ			rwx	OWNER@
	ACL_USER		fred		r-x	fred@foo

A chown would not affect the ACL.

A strict interpretation of POSIX ACL rules is that
because fred matches ACL_USER_OBJ, no ACL_USER for
fred would be relavent. The odd part is that this is true
even if the ACL_USER for fred grants more rights
than ACL_USER_OBJ. The later prevails with its
narrower rights.

Now, of course, the tricky question is what are the
semantics of NFSv4 ACLs?

	-gww

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Carl Beame
> Sent: Monday, March 03, 2003 1:49 AM
> To: [email-masked]
> Subject: Re: ACL in NFSv4 protocol
> 
>

---

From: Carl Beame <[email-masked]>
Date: 03 Mar 2003 13:21:30 +0000

> A chown would not affect the ACL.

I don't understand POSIX ACLs, but I didn't say there was an ACL for FRED@FOO, I
just said there was a mode (700). Does this mean on POSIX that it automatically
creates an ACL for user FRED???? On non-POSIX systems, were ACLs not separate
entities and doing a "CHMOD 700 l.l" just set the mode in the inode and did
nothing to the ACLs. Adding an ACL for a specific user, did it also create ACEs
for the "OWNER", "GROUP", "OTHER"???

> Now, of course, the tricky question is what are the

Good question.

- Carl

---

From: "Sergey Klyushin" <[email-masked]>
Date: Mon, 3 Mar 2003 10:16:07 -0800

> From: Mike Eisler [mailto:[email-masked]]
> Sent: Saturday, March 01, 2003 11:08 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
....... (removed)
> with the corresponding ACEs.

Actually synchronization (if needed) should be done not with "OWNER@", 
"GROUP@", and "EVERYONE@" ACEs, but with access rights that user may
approximate from mode and from ACL. In this case OWNER@/GROUP@ (as POSIX 
ACL_USER_OBJ/ ACL_GROUP_OBJ) are not necessary.

> does not. A Windows NFSv4 server should be able to derive mode from the

Windows has "read-only" attribute which is analog to "mode" in UNIX.
NTFS has ACL in addition to "read-only" attribute and they are not 
synchronized by Windows. You are right that Windows NFS Server builds mode
based on ACL and "read-only" attribute and NFS Server may synchronize them,
but not Windows OS itself.

> Well the text came from Carl. :-)

Yes, about 3 years ago and idea/interpretation was changed later.

> such an entity), then these are more attributes, and it are not going

It's not attribute. It's ACE with special "who" name. It doesn't require 
.x changes.

> is one of the special ones (that have a trailing '@').

I read it like if ACE4_IDENTIFIER_GROUP is on, then ACE identifies
owner_group, but not any group. That's why I thought that by adding
ACE4_IDENTIFIER_OWNER flag we won't need OWNER@/GROUP@ (as POSIX
ACL_USER_OBJ/ACL_GROUP_OBJ)

> > 1. Why do we need OWNER@/GROUP@ ACE in ADDITION to ACE[s] of real

Actually I did and that's why I wrote the email. Direct mapping of POSIX 
ACL_USER_OBJ/ACL_GROUP_OBJ to NFSv4 OWNER@/GROUP@ is quite different from
the original idea of NFSv4 OWNER@/GROUP@.

> of thew file owner and group owner).

Which has nothing to do with access rights of REAL owner. Test_user_1 is 
owner, ACL looks like this:
OWNER@ ALLOW ACE "-w-"
Test_user_1 has ALLOW ACE "r-x"

Following NFSv4 ACL semantic, Test_user_1 will have "rwx" access.

> > ACE[s] in Windows manner like CREATOR_OWNER/CREATOR_GROUP?

Why? It's just wording. No .x file changes (may be adding 
ACE4_IDENTIFIER_OWNER define only).

> > not listed in the protocol could be checked at [some place]."

4.1 ?

> needs to define the semantrics of future special ids.

Agreed. There are special ids like OWNER@/GROUP@/EVERYONE@ and they are
special because of their names and meaning, and interpretation of such
special ids MUST be specified in protocol.
There is also another type of special ids that are meaningful only for
some OS. NFSv4 protocol says that such ids could be stored by Server, but
their interpretation OS specific. I was talking about second type.
Hopefully these two types will be equal some day -:)

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

??? 
Again misinterpretation. And asked Carl -:)
The original idea of special EVERYONE@ ACE is to include owner and group.
If definition of "The world" doesn't include owner and group, then
============= from protocol =========
   Who                    Description
   _______________________________________________________________
   "EVERYONE"             The world.
============================================
should be changed.

> environment produces an error, then ATTRNOTSUPP seems reasonable.

Yes, it's not harmless, but indicates Client/Server implementation error.
Returning ATTRNOTSUPP will mislead Client/Server that ACL is not supported 
at all (or particular ACL type). Maybe we can live with this in 4.0 if .x 
file should be changed, but it could be useful to reconsider returning error
in 4.1
 
> that deny to the owner and group?).

Yes, it can, and I do realize that it's implementation issue.
I just wanted to ask if there are other OS that distinguishes NULL and empty

ACL and if it will be useful to add NULL ACL to protocol.
 
> It's up to server implementation.

Does any customer likes the idea that his applications work differently
with different NFS Servers?

> Not necessary, since mode is synchronized with ACL.

My example for the case when mode is not synchronized with ACL

> > - If there are no such additional sources for access checking, then

OK. Let's look at spec again:
================================
   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 no mode than as you said above
> Access is define by the ACL.
If there is mode and mode is synchronized with ACL there is no need to check
anything else.
If ACL is fully processed and access is undefined then mode is not 
synchronized with ACL

Thanks,
Sergey

---

From: "Sergey Klyushin" <[email-masked]>
Date: Mon, 3 Mar 2003 10:53:07 -0800

> when _NO_PROPOGATE_ is set.

No, the text says about "Normally" setting two ACEs on a newly created 
directory if parent directory has ACE with INHERIT flag, and setting
only one ACE if there is NO_PROPAGATE flag.

I am not saying that setting two ACEs is wrong, I am saying that it's not
necessary to be "Normal".

Here is from our discussion with Carl (please, note that text is about 3 
years old):
---------------------
Sergey:
Why "Normally ... two ACEs are placed on the new directory"?

Carl:
If a new directory is created, you would place an ACE on the directory
which is the "NORMAL" version of the INHERITED ACE. For example if the DENY 
OTHER INHERITABLE ACE is on the main directory, when a new directory (call 
it ONE) is created (assuming DIRECTORY_INHERIT_ACE is on), a simple DENY 
OTHER ACE is placed on the directory. Now when new directories or files 
(call it TWO) are created in this new directory does the user want the DENY 
OTHER to be placed on the files(TWO)? To get this to happen a second ACE 
which is an INHERIT_ACE DENY OTHER must also be placed on the first new 
directory created (ONE). This is the default action. To stop this the
NO_PROPAGATE_INHERIT_ACE flags is set on the MAIN directory ACE.

Sergey:
Description of ACE4_FILE_INHERIT_ACE and ACE4_DIRECTORY_INHERIT_ACE flags
implies that ACEs with these flags MUST be considered on access checking, 
while ACE with flag ACE4_INHERIT_ONLY_ACE MUST NOT. So, creating one ACE
with INHERIT_ACE flag on newly created directory is enough.

Carl:
What you are missing is that two ACEs are created unless the NO_PROPAGATE
is set. This is so that the user can change the acces permitted in the ACE
which refers to the newly created directory without changing the default
inheritable access.

Sergey:
I believe setting 1 or 2 ACEs is implementation choice.
In your 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.
In my scenario user always may add explicit ACE to a directory if he
wants to change default inheritable access and keep inheritable ACE in 
place. The question is how often user wants to do so to pay the price 
of double ACEs or inconvenience of adding one more explicit ACE.
BTW, Windows doesn't create 2 ACEs (at least NT 4 SP6a, 2000/XP).

Carl:
I really don't know which is "right" or which benifits the most.
------------------------------------

Thanks,
Sergey

---

From: "Sergey Klyushin" <[email-masked]>
Date: Mon, 3 Mar 2003 11:29:30 -0800

> be able to support this semantic.

Unfortunately, it's not "an implementation dependency". 
=========== from spec ==========
   ACE4_FILE_INHERIT_ACE
   Can be placed on a directory and indicates that this ACE should be
   added to each *NEW* non-directory file created.
================================
My understanding is that NFSv4 doesn't allow to modify ACL of EXISTING 
child objects.

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.

Thanks,
Sergey

---

From: "Gordon Waidhofer" <[email-masked]>
Date: Mon, 3 Mar 2003 12:30:35 -0800

For POSIX ACLs, the mode is synchronized to
three ACEs: ACL_USER_OBJ (0700), ACL_GROUP_OBJ (0070),
and ACL_OTHER_OBJ (0007). These ACEs are a kind of
indirection, refering to the current owner of the file.
A valid ACL has one and only one of each. An invalid ACL
is rejected when the attempt is made to change it. A chmod
is reflected in the mode and in those ACEs (though under
the covers it may be the same data structure). A chown/chgrp
does not alter the ACL. The ambiguity between
ACL_USER_OBJ/owner=fred and ACL_USER/fred is resolved
in favor of ACL_USER_OBJ. If the owner is changed,
ACL_USER_OBJ/owner=george, the ACL_USER/fred ACE is
not modified and becomes relavent for fred's access.

The intent of NFSv4 OWNER@/GROUP@/EVERYONE@ could be like
POSIX ACL_USER_OBJ/ACL_GROUP_OBJ/ACL_OTHER_OBJ. Or it
could be like NT ACL CREATOR_OWNER/CREATOR_GROUP.

The surprise is that CREATOR_OWNER is only used in directory
ACLs as an inherit-only ACE. Apparently, there is nothing
in NT ACLs that corresponds to the indirection of POSIX
ACL_USER_OBJ. Perhaps we thought that CREATOR_OWNER was
equivalent to ACL_USER_OBJ, and we could conveniently
refer to either as OWNER@. I know I did. I believe the
consternation of mode synchronization, fiddling ACEs that
correspond to the current owner, etc, is born of this
misunderstanding.

CREATOR_OWNER is not like ACL_USER_OBJ, and OWNER@ can
not refer to both. So what does OWNER@ refer to?

	-gww

> Sent: Monday, March 03, 2003 5:22 AM
> To: [email-masked]; [email-masked]
> Subject: RE: ACL in NFSv4 protocol
> 
>

---

From: "Eric Sedlar" <[email-masked]>
Date: Tue, 4 Mar 2003 10:34:43 -0800

> with different NFS Servers?

Isn't it the case that whatever implementation choices the server makes as
far as implementing ACLs, they must be disclosed to the client via a flag,
so that the client can evaluate the ACL in the same way on behalf of the
server?  If a client is caching content for a server, and especially sharing
that content to multiple users, the client needs to provide the same ACL
semantics as the server to avoid introducing security holes.

This means you guys actually need to come to a resolution on this
discussion, and are not allowed to punt by leaving things to be server
implementation-dependent.  No pressure, though ;-)

For what it's worth, my vote is to allow servers not to support mode, not do
any synchronization, and make the client figure out any mode synchronization
if desired.

--Eric

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 4 Mar 2003 15:03:32 -0600

> semantics as the server to avoid introducing security holes.

Clients holding a delegation can always call ACCESS on the server to
evaluate ACLs, no?

> implementation-dependent.  No pressure, though ;-)

See above.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 4 Mar 2003 15:48:29 -0600

True.

On Tue, Mar 04, 2003 at 01:44:33PM -0800, Eric Sedlar wrote:
> Seems like it defeats most of the purpose of caching if you have to do a
> server
> round trip before every NFS operation requiring an access check just to
> check
> for access control.  Wouldn't it be better to find a way to ensure that the
> client
> can evaluate the ACL itself?
> 
> --Eric
> 
> ----- Original Message -----
> From: "Nicolas Williams" <[email-masked]>
> To: "Eric Sedlar" <[email-masked]>
> Cc: "Sergey Klyushin" <[email-masked]>; "'Mike Eisler'"
> <[email-masked]>; <[email-masked]>
> Sent: Tuesday, March 04, 2003 1:03 PM

---

From: "Eric Sedlar" <[email-masked]>
Date: Tue, 4 Mar 2003 13:44:33 -0800

--Eric

---

From: Ted Anderson <[email-masked]>
Date: Thu, 06 Mar 2003 08:40:06 -0500

On 3/4/2003 16:44, Eric Sedlar wrote:
 > Date: Tuesday, March 04, 2003 1:03 PM

 > Seems like it defeats most of the purpose of caching if you have to do
 > a server round trip before every NFS operation requiring an access
 > check just to check for access control.  Wouldn't it be better to find
 > a way to ensure that the client can evaluate the ACL itself?

Not at all.  The client just caches the result of the access call along 
with the user on whose behalf it was made.  These pairs can be used to 
do permission checks in the client.  This is what AFS and DFS do.

Ted Anderson

---

From: "Eric Sedlar" <[email-masked]>
Date: Thu, 6 Mar 2003 10:58:22 -0800

* It's still an extra round trip to do ACCESS
* You've marginalized the benefit of client-side caching in that each new
user accessing the cache requires a server round trip

However, this method does give more flexibility to server implementors with
custom ACL semantics.  Either way, though, the NFSv4 spec should specify how
the client is to handle ACL evaluation.

--Eric

----- Original Message -----
From: "Ted Anderson" <[email-masked]>
To: "Eric Sedlar" <[email-masked]>
Cc: "Nicolas Williams" <[email-masked]>;
<[email-masked]>
Sent: Thursday, March 06, 2003 5:40 AM
Subject: Re: ACL in NFSv4 protocol