Re: [nfsv4] Re: [NFS] NFSv4 ACL and POSIX interaction / mask, draft-ietf-nfsv4-acls-00 not ready

On Fri, Jul 14, 2006 at 01:05:13PM -0700, Yoder, Alan wrote:
>    The hell comes from having to explain this on the phone
> to mystified customers.

Understood.

>    But it sounds like you're telling me an admin will
> never be able to see different permissions on files depending
> on what OS she happens to be looking at them with.  Is that
> correct?

It's not the OS so much as the ACL model.  Depending on what you and
your clients support, users may be looking at:

	1. Windows ACLs (over CIFS)
	2. Pure NFSv4 ACLs
	3. Pure NFSv4 ACLs with the mask attributes as proposed by Andreas
	   to make them meet POSIX requirements.
	4. "POSIX" draft ACLs, which their client got either from the v2/v3
	   sideband protocol or which they got as NFSv4 ACLs and then
	   translated (with or without the help of the new mask attributes.)
	5. mode bits

Obviously these can't all be identical.

But they should all be have the same meaning to the extent allowed,
hopefully erring on the side of showing users more permissive
permissions than are really enforced.

Of course, they're all going to encounter the same effective
permissions, because those are enforced at the server.

To expand on the specific example above: if a user of ACL model #3 sees:

	group_class_mask READ
	OWNER@    ALLOW  READ+WRITE
	bfields   ALLOW  READ+WRITE
	GROUP@    ALLOW  READ
	EVERYONE@ ALLOW  READ

then a user of ACL model #1 will see:

	OWNER@    ALLOW  READ+WRITE
	bfields   ALLOW  READ
	GROUP@    ALLOW  READ
	EVERYONE@ ALLOW  READ

The two determine identical access--the first model just gives some
extra information about what will happen on chmod.

The extra complexity introduced by the mask ACL may be nothing compared
to what you've got if you're already supporting the old sideband NFS ACL
protocol, mode bits, and v4/windows ACLs.  But it's still extra
complexity, so it's reasonable to ask whether it's worth it.

But keep in mind that if you're dealing with clients doing POSIX ACL
translation than currently you're seeing ACLs that look like

	OWNER@    ALLOW  READ
	OWNER@    DENY   everything but READ
	bfields   DENY   everything but READ
	bfields   ALLOW  READ+WRITE
	bfields   DENY   everything but READ+WRITE
	GROUP@    DENY   everything but READ
	GROUP@    ALLOW  READ
	GROUP@    DENY   everything but READ
	EVERYONE@ ALLOW  READ
	EVERYONE@ DENY   everything but READ

...and that's leaving out all the details of which mode bits are
*really* being set.  So anything that helps us get away from that kind
of stuff will be welcomed....

--b.

_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4