Subject: [nfsv4] Minor versioning and SETATTR

From: James Morris <[email-masked]>
Date: Tue, 12 Jun 2007 14:50:57 -0400 (EDT)

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
<[email-masked]>

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

---

From: "Noveck, Dave" <[email-masked]>
Date: Tue, 12 Jun 2007 15:12:12 -0400

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:[email-masked]] 
Sent: Tuesday, June 12, 2007 2:51 PM
To: [email-masked]
Subject: [nfsv4] Minor versioning and SETATTR

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

- James
-- 
James Morris
<[email-masked]>

---

From: "Sergey Klyushin" <[email-masked]>
Date: Tue, 12 Jun 2007 16:16:29 -0400

Please ignore

---

From: "Sergey Klyushin" <[email-masked]>
Date: Tue, 12 Jun 2007 17:42:25 -0400

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