Ok. Well, I can confirm that Linux, NetApp, and it appears FreeBSD doesn't do this, so I was hoping that Solaris wouldn't be the odd ball here.
On 10/24/06, Spencer Shepler <spencer.shepler at sun.com> wrote: > On Tue, Joe Little wrote: > > So, I'll ask the stupid question here if there is anyway to avoid this > > from the server, just as disabling this? > > Unfortunately, no. There is no tunable in the NFS server to modify > the behavior. > > Spencer > > > > > On 10/24/06, Spencer Shepler <spencer.shepler at sun.com> wrote: > > > > > >Joe, > > > > > >With the "chmod g+s" done first, "mandatory file locking" has been > > >enabled because the execute bit has not been set. The NFS server > > >doesn't like files that are enabled for mandatory file locking > > >because it can be blocked when it goes to read/write from that file (**). > > > > > >The failure of "cat" occurs when the client is checking access > > >with the ACCESS NFS call and the server sees that mandatory file > > >locking is possible on the file (setgid without execute) and will > > >deny read/write accesa; therefore, cat fails. > > > > > >This will occur regardless of client; interesting to note that the > > >Solaris chmod command will not allow a "chmod g+s" if the execute > > >bit is not set. It will provide a warning and set the permission > > >but without setgid. The user must ask for the mandatory file locking > > >with the +l flag. > > > > > >Spencer > > > > > >** The NFS server and underlying filesystems actually have a way to > > >avoid blocking the server on mandatory locked files but there is > > >a possibility that a filesystem may not abide by all the rules and > > >therefore we have a paranoid NFS server. > > > > > > > > >On Tue, Joe Little wrote: > > >> Snoop attached, Its ZFS backend > > >> > > >> Test was to create a file "touch file" over NFS from an ubuntu 6.10 > > >> client of a B47 OpenSolaris server. That succeeded. I then ran "chmod > > >> g+s" without first running "chmod g+x". That succeeds. Finally, I run > > >> "cat file" and the resulting snoop is what happens, with a "cat: file: > > >> Permissions denied" on the client. > > >> > > >> > > >> > > >> On 10/23/06, Spencer Shepler <spencer.shepler at sun.com> wrote: > > >> >On Mon, Joe Little wrote: > > >> >> I have B47 bits on one of my servers, nad we recently discovered > > >> >> something odd. Users from linux clients, if they have add a +s to a > > >> >> file's group permissions w/o an +x there first, would actually lose > > >> >> read access to the file itself (permission denied). It would seem that > > >> >> the file handles are no longer correct for a rwxr-Sr-x type file > > >> >> (incorrect assignment and all). > > >> >> > > >> >> It took a bit to figure out that added the execute bit returned the > > >> >> file to the owner, but why should altering group permissions ever > > >> >> effect the owner? > > >> >> > > >> >> Again, this is only with a Solaris NFS server and so far has been seen > > >> >> on linux NFS clients. It definitely smells/tastes like an error. > > >> > > > >> >Hi, Joe. > > >> > > > >> >Info about the underlying filesystem at the Solaris server and a > > >> >binary snoop trace of the failing interaction would be the next > > >> >steps to determining the root of the problem. > > >> > > > >> >Spencer > > >> > > > > > > > > > > >
