Solaris has been like this for a very, very long time. Spencer
On Tue, Joe Little wrote: > 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 > >> >> > > >> > > >> > > >> > > >
