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

From: <jcarroll65_at_cfl.rr.com>
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).

JC
---- jcarroll65@cfl.rr.com 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
>
>
> ---- jcarroll65@cfl.rr.com 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
groupA
> > 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
the
> > command line. If I create a simple C program I can remove the file.
However,
> > the application can read the file but cannot do move or remove the file.
My
> > guess is that the program run by userB  is not recognizing the secondary
group
> > membership. If I change permissions to wide open  (777) the program works.
Is
> > this bnormalb or is the program doing something that can be fixed? (I
have
> > no visibility
> >
> > JC
> > _______________________________________________
> > sunmanagers mailing list
> > sunmanagers@sunmanagers.org
> > http://www.sunmanagers.org/mailman/listinfo/sunmanagers
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers
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