newgrp and groups assigned via pam_group.so

Question

For convenience reasons I tend to assign special group memberships like floppy, audio, plugdev, video etc. via /etc/security/group.conf (pam_group.so) mechanism instead of adding all users to this groups on the directory server.

This works fine for device access, but it tends to cause trouble when external programs try to check user membership of a particular group by means of getgrent.

Now I tried to newgrp to one of this groups and recognized that this is not possible (system is Debian squeeze). Is this a bug in newgrp or just a configuration problem on my site?

What is newgrp actually doing on the Unix API side? Looks like setgid is a root-only system call. I would have thought that it would be allowed as well if the particular user is a member of the setgit target group.

I actually stumbled across the problem because mount.davfs keeps telling me that I am not a Member of the davfs2 group which is of course the case but this is also a pam_group.so assigned group.

Answer 1

newgrp only gives you access to a group that you already have access to. Sounds useless? Basically, yes. It's mostly a leftover from the days when a process couldn't be a member of multiple groups. You can also gain access to a group that's protected by a password, but that's extremely uncommonly used.

From the kernel's point of view, each process is in one or more groups. setgid can only be used when running as root or in setgid programs (to swap between the real (run-by) and effective (run-as) groups). The kernel doesn't know about user and group databases.

User and group databases (/etc/passwd, /etc/group, /etc/security/group.conf, LDAP, …) are managed by login, su and other programs that manage logins and privilege elevation, often through PAM. When you log in, you get assigned to the groups listed in /etc/passwd, /etc/group, and other files through pam_groups; the process looks like this:

gid_t groups[…] = /*extra GIDs computed from /etc/group and so on*/;
setgroups(sizeof(groups)/sizeof(gid_t), groups);
setgid(gid); /*main GID read from /etc/passwd*/
setuid(uid);
execve(shell, "-sh"); /*shell read from /etc/passwd*/

In words: renouncing root privileges (i.e. changing to the target user) is done after all other privilege management, just before invoking the user's shell. After the process is no longer running as root, it can't gain any extra groups.

If you've just added a user to a group, this will take effect the next time the user logs in. If you start another session by logging in in another terminal or over ssh, the processes in that session will have whatever groups your user was in at the time you logged in. You can use the groups or id command to see what groups you (meaning the particular process you launched groups from) are a member of.

So, I've answered your explicit questions (newgrp is doing its job, which isn't what you thought). I may or may not have solved your problem. It's unusual for applications that don't log you in to look up user and group databases; normally access permissions would be decided by checking whether the requesting process is a member of the relevant group. If you have a problem with a particular application, tell us which.

Answer 2

The reason newgrp cannot change groups in your cases is that it uses getgrent to determine whether you are a member of the requested group; see function find_matching_group in the newgrp.c source file.

Why does newgrp need to perform this check? Because the set of groups a process belongs in (the so-called "group vector") is an abritrary list: the kernel does not know about /etc/group or any other group database, and setgroups can take an arbitrary list of groups. Therefore, deciding which groups should be in a process' group vector is a matter of policy: the policy implemented by [newgrp] and most other user-space tools is to read the group vector via getgrent. (Gilles' answer provides details on this.)

On the other hand, pam_group implements a different policy: it can augment the group vector with groups that a user is not part of (according to /etc/group or LDAP).

So, in the end, two different policies exists, and mount.davfs2 complains because it assumes that only the first one is in effect. You could probably report this as a bug against mount.davfs2, or just add all the DAV users to the appropriate group in LDAP or /etc/group, or use a FUSE-based DAV filesystem instead.