Directory setgid bit does not work properly when using a Linux client and an OpenSolaris server

[David Brodbeck]

I'm mounting an NFSv4 filesystem from an OpenSolaris server, with a Linux client. The setgid bit on directories does not work consistently; files created under the directory inherit the directory's group, as expected, but directories do not.

I've been able to reproduce this with both RedHat 5.4 and Debian Lenny clients, and OpenSolaris 2009.06 and 2010.03-preview servers.

I get the expected behavior when the client and server are both Linux or both OpenSolaris, or if I use NFSv3.

Has anyone else seen this? Is it a known bug? I'm not sure which OS "owns" it, but I could get some packet captures if it would help.

[J. Bruce Fields]

Post by David Brodbeck
I'm mounting an NFSv4 filesystem from an OpenSolaris server, with a Linux client. The setgid bit on directories does not work consistently; files created under the directory inherit the directory's group, as expected, but directories do not.
I've been able to reproduce this with both RedHat 5.4 and Debian Lenny clients, and OpenSolaris 2009.06 and 2010.03-preview servers.
I get the expected behavior when the client and server are both Linux or both OpenSolaris, or if I use NFSv3.
Has anyone else seen this? Is it a known bug? I'm not sure which OS "owns" it, but I could get some packet captures if it would help.

Off the top of my head, it doesn't sound familiar. Packet captures
showing the various cases would be helpful.

--b.

[David Brodbeck]

Here are some captures of directory creations in setgid directories; first a Linux client vs. an OpenSolaris server, then a Linux client vs. a Linux server, then an OpenSolaris client vs. an OpenSolaris server. There's some extraneous LDAP stuff in these captures, too, but they were so small (~18 packets) that it didn't seem worth re-doing them to filter it out.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: linux-osol.cap.gz
Type: application/x-gzip
Size: 1205 bytes
Desc: not available
Url : http://linux-nfs.org/pipermail/nfsv4/attachments/20100405/b187572b/attachment.gz
-------------- next part --------------
A non-text attachment was scrubbed...
Name: linux-linux.cap.gz
Type: application/x-gzip
Size: 1313 bytes
Desc: not available
Url : http://linux-nfs.org/pipermail/nfsv4/attachments/20100405/b187572b/attachment-0001.gz
-------------- next part --------------
A non-text attachment was scrubbed...
Name: osol-osol.cap.gz
Type: application/x-gzip
Size: 1209 bytes
Desc: not available
Url : http://linux-nfs.org/pipermail/nfsv4/attachments/20100405/b187572b/attachment-0002.gz
-------------- next part --------------

Post by J. Bruce Fields

Post by David Brodbeck
I'm mounting an NFSv4 filesystem from an OpenSolaris server, with a Linux client. The setgid bit on directories does not work consistently; files created under the directory inherit the directory's group, as expected, but directories do not.
I've been able to reproduce this with both RedHat 5.4 and Debian Lenny clients, and OpenSolaris 2009.06 and 2010.03-preview servers.
I get the expected behavior when the client and server are both Linux or both OpenSolaris, or if I use NFSv3.
Has anyone else seen this? Is it a known bug? I'm not sure which OS "owns" it, but I could get some packet captures if it would help.

Off the top of my head, it doesn't sound familiar. Packet captures
showing the various cases would be helpful.
--b.

[Jeff Layton]

On Mon, 5 Apr 2010 13:39:45 -0700

Post by David Brodbeck
Here are some captures of directory creations in setgid directories; first a Linux client vs. an OpenSolaris server, then a Linux client vs. a Linux server, then an OpenSolaris client vs. an OpenSolaris server. There's some extraneous LDAP stuff in these captures, too, but they were so small (~18 packets) that it didn't seem worth re-doing them to filter it out.

The Linux client assumes that the server will take care of the "chgrp"
in this case. Solaris seems to assume that it's the responsibility of
the client.

The problem with assuming that it's the responsibility of the client is
that the client may not have the proper privileges to change the group.
If Solaris is setting the group properly for files but not directories,
then that's probably a server bug.

[David Brodbeck]

Post by Jeff Layton
On Mon, 5 Apr 2010 13:39:45 -0700

Post by David Brodbeck
Here are some captures of directory creations in setgid directories; first a Linux client vs. an OpenSolaris server, then a Linux client vs. a Linux server, then an OpenSolaris client vs. an OpenSolaris server. There's some extraneous LDAP stuff in these captures, too, but they were so small (~18 packets) that it didn't seem worth re-doing them to filter it out.

The Linux client assumes that the server will take care of the "chgrp"
in this case. Solaris seems to assume that it's the responsibility of
the client.
The problem with assuming that it's the responsibility of the client is
that the client may not have the proper privileges to change the group.
If Solaris is setting the group properly for files but not directories,
then that's probably a server bug.

Thanks, Jeff. I suppose my next step will be to file a bug against OpenSolaris and see what the folks over there say.

[David Brodbeck]

Post by David Brodbeck

Post by Jeff Layton
On Mon, 5 Apr 2010 13:39:45 -0700

Post by David Brodbeck
Here are some captures of directory creations in setgid directories; first a Linux client vs. an OpenSolaris server, then a Linux client vs. a Linux server, then an OpenSolaris client vs. an OpenSolaris server. There's some extraneous LDAP stuff in these captures, too, but they were so small (~18 packets) that it didn't seem worth re-doing them to filter it out.

The Linux client assumes that the server will take care of the "chgrp"
in this case. Solaris seems to assume that it's the responsibility of
the client.
The problem with assuming that it's the responsibility of the client is
that the client may not have the proper privileges to change the group.
If Solaris is setting the group properly for files but not directories,
then that's probably a server bug.

Thanks, Jeff. I suppose my next step will be to file a bug against OpenSolaris and see what the folks over there say.

Just to follow up on this, the bug I filed was marked as a duplicate of this bug, which I somehow failed to find with my searches:
http://bugs.opensolaris.org/view_bug.do?bug_id=6894234
(OpenSolaris's bug tracking is confusing...they have two databases, and it's possible I only searched one, or just didn't hit the right set of keywords.)

It looks like the fix is in version snv_135, which means it didn't quite make the 2010.03 preview (snv_133) but should be in the release after that one. (Assuming there is one; the release that was supposed to be 2010.03 has gone missing since the Oracle merger, but that's another topic.)