Re: Summary (2): Not removing files on NFS with secondary group membership

From: <>
Date: Fri Jul 16 2010 - 16:39:15 EDT
OK, the REAL issue was the top process for the application was started BEFORE
the ID was assigned it's secondary group membership. (I don't know anything
about how the app runs and I forgot about inheritance.) A bounce of all of the
application allowed it's children to see the secondary membership.

Life is wonderful. Time for a martini (or two).

---- wrote:
> Turns out that the application uses the 'access' function to check for
read/write permissions. (I finally got the apps folks to cough up the PID.)
The man page indicates that access will only use the real UID and GID. The
secondary GID will not be used. If I force the permissions to 666 the
application runs correctly. So I'm left with having the application on system
A change permissions to 666 or (shudder) write a cronjob to do it.
> To clarify some things:
> When I wrote bdon't have access to the execution of the programb I meant
the apps folks wouldnbt or couldnbt  supply the PID. They finally
understood my request after speaking slowly and using small words. (Picture
deer in head lights. Typical of our developers.)
> ACLbs probably would not work due to the access function call and the
issue bring for files only. The application folks would have to set them. (See
above comment about developers.)
> The GIDbs by definition in the original statement are different. Note
groupA and groupB. The issue is the secondary group membership not being
bseenb by the access function.
> JC
> ---- wrote:
> > An interesting issue with NFS and secondary group membership
> >
> > The setup
> > Directory NFS shared from system A to system B
> > User ID userA is directory owner on both systems, with primary group
> > User ID userB is only on system B and has secondary membership in groupA
> > Files are read/write for groupA
> >
> > I can manipulate (mv, vi, cp, etc.)  the file on system B as userB from
> > command line. If I create a simple C program I can remove the file.
> > the application can read the file but cannot do move or remove the file.
> > guess is that the program run by userB  is not recognizing the secondary
> > membership. If I change permissions to wide open  (777) the program works.
> > this bnormalb or is the program doing something that can be fixed? (I
> > no visibility
> >
> > JC
> > _______________________________________________
> > sunmanagers mailing list
> >
> >
sunmanagers mailing list
Received on Mon Jul 19 18:32:24 2010

This archive was generated by hypermail 2.1.8 : Thu Mar 03 2016 - 06:44:17 EST