Newgrp and groups assigned via pam_group.so

grouppampermissions

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.

Best Answer

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.

Related Question