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/sunmanagersReceived 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