Subject: [nfsv4] RE: ACL in NFSv4 protocol

From: [email-masked]
Date: Thu, 1 May 2003 16:12:24 -0400

After recently reading this thread again and thinking about related issues
in the multi-protocol environment (e.g., CIFS, NFSv2/3, NFSv4), I would like
to propose a minor addition to section 5.11.4 "ACE who".  The addition is
another modifier called "OTHER" that would map directly to MODE4_*OTH mode
bits or to the POSIX ACL draft entry ACL_OTHER.  Including the OTHER
identifier cleans up some of the issues with mapping permissions between
mode bits and ACLs.  It is, perhaps, syntactic sugar, but sometimes that a
good thing.

Since the consensus seems to be leaving the interpretation of EVERYONE to be
exactly that, everyone including the owner and owning group, this seems a
straightforward addition to me.

If we are agreeable, the formal addition would be whenever the next revision
was being worked on.  Certainly not a critical issue.

--Tad Taylor

-----Original Message-----
From: Mike Eisler [mailto:[email-masked]]
Sent: Thursday, March 06, 2003 3:00 PM
To: [email-masked]
Subject: Re: ACL in NFSv4 protocol

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
_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4