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

From: Andreas Gruenbacher <[email-masked]>
Date: Thu, 3 Aug 2006 15:46:12 +0200

On Wednesday, 26 July 2006 06:59, Sam Falkner wrote:
> On Jul 25, 2006, at 2:15 PM, Andreas Gruenbacher wrote:
> >> But let's pretend that all NFSv4 clients do support the ACL
> >> attribute.  Having the chmod command unable to set the mode was a
> >> source of many customer complaints when that was the behavior in
> >> Solaris (http://xrl.us/pd7c and http://xrl.us/pd7b are just two
> >> examples of bugs).  The Solaris chmod command was fixed to alter the
> >> POSIX-draft ACL (in file systems that support POSIX-draft ACLs), so
> >> that chmod was actually able to change the mode.  Since making this
> >> change to chmod, complaints have stopped.
> >
> > Maybe nobody explained to users how to properly use ACLs to prevent
> > this from happening? The behavior of Solaris chmod(1) is a potential
> > security hole, although a small one only.
>
> I remind you that in NFSv4, ACL is not a required attribute.

I think this point has already become clear, but just so that it doesn't 
appear as if I'm selectively ignoring your arguments, let me reiterate:

I did not miss the fact that NFSv4 implementations may choose not to implement 
the ACL attribute. In the mapping I am proposing, the mode attribute always 
reflects the file mode permission bits. On a POSIX server that doesn't 
support the ACL attribute, the mode attribute represents the file mode 
permission bits which determine access.

On the other hand, a server which does support the ACL attribute, the ACL may 
induce further restrictions on the permissions granted by the mode attribute. 
In case any alternate ACE mode bits are set which are not disabled, the ACL 
may also grant permissions that go beyond the file mode permission bits.

[For servers that don't support the ACL attribute, it obviously also makes no 
sense to support file masks.]

> >> So, if we were to do as your proposed design says, and have
> >> MODE4_RGRP, etc., not reflect the mode, then once again, we would
> >> have to modify the chmod command to do more than the chmod() system
> >> call.  This is madness.
> >
> > This is not what I am proposing at all.
> >
> >> Or, we could simply have MODE4_RGRP, etc., reflect the mode of the
> >> file.
> >
> > This *is* what I am proposing. A mode SETATTR also affects which
> > permissions are effective in the ACL and which must be disabled, though.
> > Both proposals disable permissions, but they do so using different
> > mechanisms: your proposal introduces DENY ACEs spread throughout the
> > ACL. My proposal sets masks, which are only applied in the access check
> > algorithm. I argue that simply updating the masks is a much nicer way of
> > achieving the same effect, and that it avoids the problems inherent to
> > those DENY ACEs.
> >
> >>> Algorithm 5.6.3. is at least problematic because it enforces
> >>> implementing masking of permissions using DENY ACEs, while an
> >>> alternative design exists that achieves the same effects without the
> >>> disadvantages of those DENY ACEs.
> >>
> >> That alternative introduces a new file attribute, which causes
> >> problems for NFSv4.0, and for Windows servers.
> >
> > That's not true. There are several ways how we can deal with clients
> > that do not understand masks:
>
> You just ignored my comment about Windows servers.

Not on purpose. I'll assume that your comment is that Windows servers do not 
(and probably will not) support the proposed file_masks attribute, which is 
pretty much the same situation as with NFSv4 (RFC3530) servers that also 
don't support this attribute.

On such a server, nothing prevents users from setting arbitrary ACLs. POSIX 
applications running on the client may chmod files, which maps to mode 
SETATTR calls. Because RFC3530 does not define the interaction between a mode 
SETATTR and the ACL attribute, those servers obviously are not guaranteed to 
implement strict POSIX semantics.

We could map a chmod to an ACL GETATTR, inject DENY ACEs on the client side as 
required, and then set both the new mode and the modified ACL. This would 
give us pretty good POSIX semantics, but implementing this hack on the client 
side sounds pretty ugly to me.

Is this what you were envisioning?

I believe that a more sane approach would be to accept that non-POSIX NFSv4 
servers will not have strict POSIX semantics, and live with the fact.

Andreas

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

---

From: Sam Falkner <[email-masked]>
Date: Thu, 03 Aug 2006 19:37:38 -0600

On Aug 3, 2006, at 6:30 PM, Andreas Gruenbacher wrote:

> Sorry this reply took a while; I was away for a couple of days.

I could write an extremely lengthy rebuttal to your extremely lengthy  
reply :-), but please, let's wait until the meeting next week.  I  
will try to have a draft of the revised ACL chapter before then...  
hopefully tomorrow.

Thanks!

- Sam

---

From: Andreas Gruenbacher <[email-masked]>
Date: Fri, 4 Aug 2006 13:19:00 +0200

On Friday 04 August 2006 03:37, Sam Falkner wrote:
> reply :-), but please, let's wait until the meeting next week.

Please do, so that I'll know what you disagree with, and why. The more issues 
of dispute we can clearly identify before the meeting, the better.

> I will try to have a draft of the revised ACL chapter before then...
> hopefully tomorrow.

That would be really helpful.

Thanks,
Andreas

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

---

From: Andreas Gruenbacher <[email-masked]>
Date: Fri, 4 Aug 2006 12:35:04 +0200

Thanks,
Andreas

---

From: Sam Falkner <[email-masked]>
Date: Fri, 04 Aug 2006 14:20:43 -0600

On Jul 21, 2006, at 9:10 AM, Noveck, Dave wrote:

>> The current ACL spec, in the minorversion1 draft and in the previous
>> ACL drafts, rigorously specifies mode/ACL interactions by specifying
>> algorithms.  Bruce had the comment that the spec read as though the
>> algorithm was mandatory.
>
> That was my reading.  Was that the intention or not?

It was, but note that there were many optional steps.  The problem  
we've since come to recognize is that there may be other algorithms  
that do the job, and we don't want to disallow that.

>> Rethinking, it would be preferable to have the ACL specification
>> specify requirements, and have the algorithms serve as examples.
>
> I think the requirements that the algorithms are intended to address,
> would be helpful in understanding, whether the algorithms are
> examples or are mandatory.

Agreed.

>> Or,
>> rewrite the sections as requirements, and release algorithms outside
>> the minorversion1 draft, possibly through one or more informational
>> RFCs.  This would shorten the minorversion1 draft, without
>> invalidating the existing semantics.
>
> I think this would complicate understanding and review.  Even if
> the algorithms are examples and not mandatory, I would imagine
> they would be helpful in understanding the requirements and their
> implications, and if they are helpful, they should be in the spec,
> with an indication that they are illustrative and not mandatory.

I agree.  How about this: we move the algorithms into an appendix of  
minorversion1.  The appendix will expressly state that the algorithms  
are illustrative.  By having them in an appendix, they will be  
available, as opposed to moving them toward a separate informational  
RFC.

>> We'll try to have an initial draft of the ACL parts of the
>> minorversion1 document on August 7.  I'll also add an issue to nfs4-
>> editor.org.
>
> Here's a couple of other things I've noted that you might consider
> while working in this area:
>
>     There is statement about not using additional mode bits beyond
>     the ones defined but there is a "MUST NOT" addressed to the world
>     in general.  I think the mandate should be for the server.  It  
> MUST
>     NOT return other bits on GETATTR and MUST return NFS4ERR_INVAL if
>     other bits are set on SETATTR or CREATE/OPEN-create.  The  
> client is
>     free to use whatever bits he wants.  He is not disobeying the
> protocol
>     but he will get NFS4ERR_INVAL.

Done.

>     I don't see the point of allowing multiple behaviors in the  
> case in
>     which both MODE and ACL are set.  Rather than rell the client  
> how to
>
>     deal with all possible server behaviors, consider mandating the
> order
>     in which a SETATTR/CREATE with both MODE and ACL will be processed
> by
>     the server.  I think that would make life simpler for everybody.
> The
>     server knows what order he should do these in and the client knows
>     which order the changes will be done in.

Done.  Yes, this is much simpler.

* * *

Okay, here's the revised text.

http://www.nfsv4-editor.org/cgi-bin/roundup/nfsv4/file29/acls.txt

Please forgive the fact that the appendix appears as "Section 3"; it  
will eventually land in a proper appendix.

Regarding Spencer's question from before, about "ACL compatibility  
goals for NFSv4.1", this revised chapter qualifies as additional  
explanatory text.  Nothing is broken from RFC 3530, only clarified.   
Nothing new is proposed.  To my knowledge, the clients and servers  
that have been tested at the various Connectathon and Bakeathon  
events are fine with this spec.

- Sam