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

[Andreas Gruenbacher <[e-mail]>]

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
[e-mail]
https://www1.ietf.org/mailman/listinfo/nfsv4