Subject: RE: ACL in NFSv4 protocol

From: "wurzl, mario" <[email-masked]>
Date: Sun, 2 Mar 2003 12:17:11 -0500

> -----Original Message-----
> From: Mike Eisler [mailto:[email-masked]]
> Sent: Sunday, March 02, 2003 2:08 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: ACL in NFSv4 protocol
> 
> 
> > 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.
If your server supports only NFSv4, then you probably don't need to worry
about synchronization, and may be you should support only ACL.
But, for muti-protocol servers NFSv2/3/4 and/or NFS//CIFS, synchronization
between mode-nits and ACEs is necessary.
> 
> > I consider synchronization of mode and ACL as a biggest 
> issue of ACL in
> > NFSv4.
Yes it is. And if we want to have migration and replication of file-systems
to happen between servers of different vendors, then all vendors should
implement the same mode-bit/ACE synchronization semantics, else access to a
file from one server may have different results than access to the same file
when replicated to a server from another vendor.

I believe that the NFSv4 spec. should clearly specify the synchronization
and access control semantics.
> 
> > 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.

No. It should stay, but the synchronization semantics have to be explained.
> 
> > 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.

Even if we do not change the v4.0 spec, we may still come to an informal
agreement.
> 
> > 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.

Yes. The problem will still exist. Because of the ACL check, a user may not
have access to a file, even though the mode-bits do grant the user the
required access.
> 
> 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: Wu Zheng <[email-masked]>
Date: Tue, 4 Mar 2003 11:54:13 -0600

Enjoy reading the discussion.  Please see comments below,

Wu Zheng
[email-masked]
Phone: (512) 838-0558    T/L: 678-0558
11400 Burnet Road,  Austin, TX 78758

"Sergey Klyushin" <[email-masked]>@sunroof.eng.sun.com on
03/03/2003 02:35:27 PM

Sent by:    [email-masked]

To:    "'Mike Eisler'" <[email-masked]>, <[email-masked]>,
       <[email-masked]>
cc:
Subject:    RE: ACL in NFSv4 protocol

> I believe that definition of OWNER@/GROUP@/EVERYONE@ should be solved
first
> and only after we need to return to synchronization issue.
>
> We have to agree->disagree->and finally agree on the following
> 1. EVERYONE@ includes owner and group and all other special "who" ids.

Agree

> 2. What is special "who" ids OWNER@/GROUP@
> 2.1 Direct mapping/meaning of POSIX ACL_USER_OBJ/ACL_GROUP_OBJ or
> 2.2 Direct mapping/meaning of Windows CREATOR_OWNER/CREATOR_GROUP ACE or
> 2.3 "I (Carl) 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."
> 2.4 All above or non from above -:)

GROUP@ represents the current group of the file. Most of time the file
owner
is in the group, as a result GROUP@ includes the file owner. Do we agree on
this?

NOTE: The unix mode permission for group does not apply to the file owner
even when
the owner belongs to the group. I assume that ACE for ACL_GROUP_OBJ does
not apply
to the file owner in POSIX either. If this is the case, "2.1 Direct
mapping/meaning of POSIX ACL_USER_OBJ/ACL_GROUP_OBJ" is elimitated from the
list.

> 3. Whatever OWNER@/GROUP@ is, may ACL include ACE for real owner/group in
> addition to OWNER@/GROUP@.

Yes.
Because disallowing real owner/group ACEs will not limit the evaluated ACEs
for owner and group to OWNER@ and GROUP@ only. There are other ACEs
which apply to owner and group implcitily.

For example:
   joe is a member of group foo
   ACE1: ALLOW r OWNER@
   ? ACE2: ALLOW rw joe
   ? ACE3: ALLOW rw foo(group)

We assume that ACE1 exists. If we allow ACE3 then we should allow ACE2.
It is too restricting to not allow ACE3.

> 4. Whatever OWNER@/GROUP@ is, may ACL include more than one ACE of
> OWNER@/GROUP@.

Yes.
First, we need at least two ACEs, one for ALLOW and one for DENY.
(maybe more for ALARM and AUDIT)

Second, there is no limitation on number of ACEs for other users and
groups,
why start with OWNER@ and GROUP@.

Third, the reletive positions of OWNER@/GROUP@ ACEs to other ACEs is a
bigger
issus then the number of OWNER@/GROUP@ ACEs. If we can not put restriction
on
the ACL order, we should not put restriction on number of ACEs.

> 5. Should OWNER@/GROUP@ be "storable".

I am still thinking about this one.

> 6. Is special ACL processing required for user/group that is file owner/
> owner_group (not to process all ACL, but OWNER@/GROUP@ only)

This makes things simple. But it breaks the beauty of NFSv4 ACL.
This is the same as have two ACLs, one for OWNER/GROUP, one for everyone
else.

> I strongly believe making agreement on this will solve synchronization
issue
> much easily.

> Thanks,
> Sergey

---

From: "Sergey Klyushin" <[email-masked]>
Date: Tue, 4 Mar 2003 13:14:58 -0800

Probably I did not express myself clear about automatic propagation of 
inheritable ACEs to existing child objects.
I was trying to say that NFSv4 protocol doesn't have full SUPPORT for this,
but NOT THAT NFS SERVER/CLIENT WILL DO IT AUTOMATICALLY. Yes, it should be 
done by application, not by NFS Server/Client.
By support I mean 2-3 flags set in ACL of directory/files that may 
protect/allow directory/file from accepting ACL changes of parent directory.
Yes, Windows NTFS doesn't do automatic propagation, but has full support for

this.

Thanks,
Sergey

> From: Sergey Klyushin [mailto:[email-masked]]
> Sent: Monday, March 03, 2003 11:30 AM
> To: 'Mike Eisler'; [email-masked]'
> Cc: [email-masked]'; [email-masked]'; [email-masked]'
> > > This question was brought to mailing list attention some time ago (I
> > guess
> > > 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
> > > 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.
> >
> 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: Mike Eisler <[email-masked]>
Date: Thu, 6 Mar 2003 12:00:08 -0800 (PST)

We've been discussing this issue at Connectathon,
and this is the current consensus among some of us
(Spencer, Seregey, and me):

OWNER@ and GROUP@

	The meaning of these identifers corresponds with the
	meaning of the USER_OBJ and GROUP_OBJ in the POSIX
	ACL draft specifications, not creator. GROUP@ and OWNER@
	ACEs can be set via SETATTR. This is what we took away from
	the Ann Arbor bakeoff in 2002.

	We recognize that there are operating environments that
	make it impossible for servers to precisely implement OWNER@
	and GROUP@. Just as POSIX-based servers will have
	a challenge implementing NFSv4 ACLs in full, Windows servers
	will have a (smaller) challege. The Windows server
	could do OWNER@ and GROUP@ as "bag on the side", with the
	downside, thhat principals accessing the files via a
	non-NFSv4 protocol (e.g. CIFS) may not experience the
	same access, since a native CIFS server in Windows isn't
	likely to reas the bad on the side. Personally, I would
	not do the bag on the side on Windows, and would instead:

	- on SETATTR, map OWNER@ and GROUP@ to file's corresponding
		owner and group owner.

	- on GETATTR, never return OWNER@ and GROUP@. 
	
	The key thing here is that the access the client
        wanted after SETATTR is preserved, even if the names changed a bit.

	For example, if file is owned by "carl", and client does:

		SETATTR "carl" r ALLOW, "OWNER@" w ALLOW

	then the Windows based server records:

		"carl" r ALLOW
		"carl" w ALLOW

	Carl gets rw access to file.

Meaning of EVERYONE@?

	Does this mean everyone but OWNER@ and GROUP@ or does
	it mean everyone including the aforemention, or
	does it mean something else?

	To me, when the mode attribute is supported,
        the distinction doen't matter, but in summary,
	EVERYONE@ means everyone, including OWNER@ and GROUP@.

Synchronizing mode with acl.

	Several of us believe that there is an unambiguous mapping
	from mode to a set of up to 6 ACEs in the ACL.
	Mode has 3 bits for user rwx, 3 for group rwx, and 3
	for other rwx. If all 3 bits of a field are one,
	then there must be an ALLOW ace for OWNER@, GROUP@, or
	EVERYONE@ that has all three acess rights. If a bit is
	missing mode for a access right, then it must show up in
	a corresponding DENY ace. So for example:

	rw- r-x -w- (0652 in octal)

	Owner has rw access, group has rx access, and other has
	w acess. The ACEs are:

		OWNER@ rw ALLOW
		OWNER@ x  DENY
		GROUP@ rx ALLOW
		GROUP@ w  DENY
		EVERYONE@ w ALLOW
		EVERYONE@ rx DENY

	If the mode is set to 0652, then the server that supports
	both mode and acl must record the corresponding aces
	(or at least be prepared to render them when a GETATTR
	for the acl is done). Also, as noted previously,
	the server may not be able to store "OWNER@" and "GROUP@"
	identifiers, and instead may have map them back to
	the real identifers of the file's owner and group.
	That's ok.
	
	From the above example, we can see that because EVERYONE@
	is listed last in the acl, that whether EVERYONE@
	means everyone, or everyone but owner and group
	is irrelevant.

Inheritance

	Sergey explained that there are acl bits in
	Windows that say whether a file wants automatic
	propogation of acl whenever the ancestor's acl is
	changed. This happens as result of Windows Explorer, not
	something in the filesystem. It seems like a useful
	work item for a future NFSv4 minor revision
	to add these bits. We need a formal proposal
	in the form of an i-d.

		-mre