old dog, meet new tricks :)
On 10/24/06, Spencer Shepler <spencer.shepler at sun.com> wrote: > > 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 > > >> >> > > > >> > > > >> > > > >> > > > > >
