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

From: "Yoder, Alan" <[email-masked]>
Date: Fri, 14 Jul 2006 13:05:13 -0700

> > Let me see if I understand.
> > 
> > A POSIX ACL client sees ALLOW bfields READ+WRITE
> 
> Not necessarily "POSIX ACL" clients, but clients that request the new
> mask attributes.  Such clients also understand that the relevant mask
> makes that ALLOW effectively the same as just an allow of READ.

   The hell comes from having to explain this on the phone
to mystified customers.  It took years for the phone to stop 
ringing after Netapp's first multiprotocol implementation.  
In fact, it still hasn't completely stopped, in spite of a
huge documentation and education effort.

   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?

Thanks,

Alan

===============================================================
Alan G. Yoder                                    [email-masked]
Technical Staff                           
Network Appliance, Inc.                            408-822-6919
===============================================================

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: "J. Bruce Fields" <[email-masked]>
Date: Fri, 14 Jul 2006 16:28:10 -0400

On Fri, Jul 14, 2006 at 01:05:13PM -0700, Yoder, Alan wrote:
> to mystified customers.

Understood.

> on what OS she happens to be looking at them with.  Is that

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.

---

From: Andreas Gruenbacher <[email-masked]>
Date: Thu, 27 Jul 2006 04:28:37 +0200

> huge documentation and education effort.

I understand your concerns. My point would be that no matter how we implement 
the correct semantics, the semantics will remain just as complex. The worst 
that could happen is that an implementation uses unsuitable abstractions and 
through that makes the semantics even less obvious, or introduces 
unintentional artefacts.

> on what OS she happens to be looking at them with.  Is that

Clients who understand the concept of masking will see that there are some 
permissions which are not efective (= masked). Clients which do not undestand 
this concept will only see the effective permissions. At least this is what I 
was proposing, so I would call your statement correct. More capable clients 
will see some additional details that are hidden from other, less capable 
ones.

Indeed it would be bizarre and wrong to show masked permissions to clients 
which do not understand masking.

Thanks,
Andreas

-- 
Andreas Gruenbacher <[email-masked]>
Novell / SUSE Labs