Subject: RE: [nfsv4] mode bits

From: "Noveck, Dave" <[email-masked]>
Date: Fri, 11 Nov 2005 08:19:38 -0500

> Would it make sense for the protocol to allow for a client
> to set just
>       const MODE4_SUID = 0x800;  /* set user id on execution */
>       const MODE4_SGID = 0x400;  /* set group id on execution */
>       const MODE4_SVTX = 0x200;  /* save text even after use */
>
> To satisfy API requests that only twiddle these bits and nothing
> else in the mode (to avoid issue with changes in ACL settings)

That covers those API requests, but what about the others?  If
someone does chmod +w, should we return INVAL (if the fs supports
ACLs?, if the file has an ACL?, only in v4.1?).  If so, what does
the client do?  I guess he could make the changes to the ACL proposed 
for mode-bit changes (in draft-falkner-nfsv4-acls-00) himself, but 
the non-atomicity of that is worrying.  

This is essentially making mode manadatory-to-not-implement-in-part.
I suppose it is the kind of thing that might be allowed by minor
versioning rules.

In retrospect, I regret that we did not do better in considering the
possible (obvious) problems of the interaction of these attributes
up front.

I think if we want to go down this road, the way to do it would be 
to add in v4.x a recommended attributes mode_highbits which people 
could support if they choose (and then not support mode).  In v4.x+n,
mode could be made not valid to support if acls were supported
on an fs.  Or maybe x+n would be high enough that acls were a required
attribute, and then mode could be mandatory to not implement at that
point.

-----Original Message-----
From: Spencer Shepler [mailto:[email-masked]]
Sent: Friday, November 11, 2005 2:47 AM
To: [email-masked]
Subject: Re: [nfsv4] mode bits

On Tue, Mike Eisler wrote:
> 
> 
> --- "Yoder, Alan" <[email-masked]> wrote:
> 
> >  
> > In section 5.11.5 RFC 3530 says
> > 
> > "The remaining bits are not defined by this protocol 
> > and MUST NOT be used.  The minor version mechanism 
> > must be used to define further bit usage."
> > 
> > I surmise that this refers to the bits MODE4_SUID, 
> > MODE4_SGID and MODE4_SVTX, which are not mentioned 
> > in the immediately foregoing paragraphs.
> 
> They are mentioned after the first paragraph of 5.11.5.
> 
> 5.11.5 has:
> 
> 5.11.5.  Mode Attribute
> 
>    The NFS version 4 mode attribute is based on the UNIX mode bits.  The
>    following bits are defined:
> 
>       const MODE4_SUID = 0x800;  /* set user id on execution */
>       const MODE4_SGID = 0x400;  /* set group id on execution */
>       const MODE4_SVTX = 0x200;  /* save text even after use */
>       const MODE4_RUSR = 0x100;  /* read permission: owner */
>       const MODE4_WUSR = 0x080;  /* write permission: owner */
>       const MODE4_XUSR = 0x040;  /* execute permission: owner */
>       const MODE4_RGRP = 0x020;  /* read permission: group */
>       const MODE4_WGRP = 0x010;  /* write permission: group */
>       const MODE4_XGRP = 0x008;  /* execute permission: group */
>       const MODE4_ROTH = 0x004;  /* read permission: other */
>       const MODE4_WOTH = 0x002;  /* write permission: other */
>       const MODE4_XOTH = 0x001;  /* execute permission: other */
> 
>    Bits MODE4_RUSR, MODE4_WUSR, and MODE4_XUSR apply to the principal
>    identified in the owner attribute.  Bits MODE4_RGRP, MODE4_WGRP, and
> 
>    MODE4_XGRP apply to the principals identified in the owner_group
>    attribute.  Bits MODE4_ROTH, MODE4_WOTH, MODE4_XOTH apply to any
>    principal that does not match that in the owner group, and does not
>    have a group matching that of the owner_group attribute.
> 
>    The remaining bits are not defined by this protocol and MUST NOT be
>    used.  The minor version mechanism must be used to define further bit
>    usage.
> 
> 
> > 
> > 
> > However, in section 5.11.6 it says
> > 
> > "Because the mode attribute includes bits (e.g., 
> > MODE4_SVTX) that have nothing to do with ACL semantics, 
> > it is permitted for clients to specify both the ACL 
> > attribute and mode in the same SETATTR operation...."
> > 
> > 
> > What am I to make of this?  Is specifying these three
> > bits in the mode allowed or not?
> 
> Yes it is allowed.

Would it make sense for the protocol to allow for a client
to set just
       const MODE4_SUID = 0x800;  /* set user id on execution */
       const MODE4_SGID = 0x400;  /* set group id on execution */
       const MODE4_SVTX = 0x200;  /* save text even after use */

To satisfy API requests that only twiddle these bits and nothing
else in the mode (to avoid issue with changes in ACL settings)

Spencer

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

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

---

From: Trond Myklebust <[email-masked]>
Date: Fri, 11 Nov 2005 09:29:08 -0500

> the non-atomicity of that is worrying.  

Note that chmod is a quite valid operation on POSIX acls (it just
modifies the mask), so a server that chooses to export POSIX ACLs via
NFSv4 (i.e. a Linux server) might prefer to allow it.

Cheers,
  Trond