Minor versioning and SETATTR

In the current NFSv4 spec, and the 4.1 draft, the minor
versioning 
guidelines state:

  Minor versions may append attributes to GETATTR4args,
  bitmap4, and GETATTR4res.


Why then not also the ability to append attributes to
SETATTR4args 
and SETATTR4res ?  Or is this implied by the subsequent
paragraph:

   This allows for the expansion of the attribute model to
allow
   for future growth or adaptation.


What I have in mind is the possible addition of new
recommended 
attributes, which may need to be settable by the client.



- James
-- 
James Morris
<jmorrisnamei.org>

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

The intetion is that attributes may be added and that they
may be settable, and not only interrogated.  Many
attributes
added in 4.1 are settable.

I agree that the minor versioning guidelines could be a 
bit clearer on this point.

-----Original Message-----
From: James Morris [mailto:jmorrisnamei.org] 
Sent: Tuesday, June 12, 2007 2:51 PM
To: nfsv4ietf.org
Subject: [nfsv4] Minor versioning and SETATTR

In the current NFSv4 spec, and the 4.1 draft, the minor
versioning
guidelines state:

  Minor versions may append attributes to GETATTR4args,
  bitmap4, and GETATTR4res.


Why then not also the ability to append attributes to
SETATTR4args and
SETATTR4res ?  Or is this implied by the subsequent
paragraph:

   This allows for the expansion of the attribute model to
allow
   for future growth or adaptation.


What I have in mind is the possible addition of new
recommended
attributes, which may need to be settable by the client.



- James
-- 
James Morris
<jmorrisnamei.org>

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

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

Please ignore

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

Hello,

Could somebody clarify what is correct behavior for NFS
Client and
Server to support SetGID bit?

I always believed that NFS Client should set appropriate
group on
file/directory create request. However recently I found
different
implementations.

Here are few examples. 
Let's say, directory "dir1" has mode 2777.

Implementation 1 (most NFS Clients):
NFS Client creates a new file with attributes that set gid
of the file
to gid of "dir1"
NFS Server follows the request.

Implementation 2 (just few NFS Clients)
NFS Client creates a new file without asking to set gid to
gid of
"dir1".
Some NFS Servers check mode of "dir1" and set gid
of the new file to gid
of "dir1". 
In this case mount options (nosuid, suid, etc.) on NFS
Client site are
ignored by NFS Server.

Some NFS Servers don't do that and set gid to gid from RPC
assuming that
NFS Client is the one who has to decide what gid to set.

Explanation for such behavior of NFS Clients could be like
that (from
another email): 
"If the client sets the gid, then you introduce a race,
because the
client's cache of the directory's gsid bit and owner_group
may be out of
date.

It may be a very unlikely race, but still--the server can
avoid this
completely, and the client can't, so it seems odd to require
the
client-side sgid implementation."

Once again, NFS Server doesn't know anything about mount
options
(nosuid, suid, etc.) and in this case will ignore them.

So, what is correct?

Thanks in advance,
Sergey Klyushin
  
  

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