getgroups (2) vs groups (1) give different results?
I'm using a customized xdm-based login manager instead of the dtlogin infrastructure on Solaris 9, and I'm getting some weird results.
The first symptom I noticed when logging in with the xdm-based manager was that 'sudo' broke. Digging into it with truss, I found that when sudo calls 'getgroups()', it gets an incorrect response. Specifically, getgroups() only reports my primary group, and none of my other groups. So, since sudo doesn't believe I'm a member of 'adm', and the sudoers specifies that members of 'adm' can execute commands as root, sudo reports that I'm not in sudoers.
To verify this, I wrote a trivial little C program that calls getgroups() and prints the results. It confirmed that getgroups() is only reporting my primary group. However if I run 'groups' on the command line, it reports my full set of groups. Digging in with truss again, I can see that the groups program does a full group lookup, going through nsswitch, which leads it to do an LDAP lookup (all of our account data, including group membership and sudoers configuration, is in LDAP) and it retrieves all of the right information.
The problem doesn't appear related to LDAP, since I can do LDAP queries just fine, and gets the right results. Switching back to Sun's dtlogin fixes everything, but I need to use this other login manager.
With all of that introduction, here's my question: Is there some script executed by the dtlogin stuff at login time that registers the user's list of groups with the kernel? It looks like getgroups() just returns group information that is somehow cached by the kernel so it doesn't have to do a full lookup every time the information is needed. I'm thinking that my Xsession, etc. scripts need to somehow set that group list. Is that right? If so, how is it done? If not, how does that list normally get initialized?
Any ideas appreciated,
Shawn.
