On Tue, Feb 24, 2009 at 02:11:36PM +0000, Jon Dowland wrote: > Finally can anyone with a deeper insight of the issues > explain whether or not the frustrating "existing logins > don't inherit new groups" behaviour is fixable, or is that > deeply rooted in UNIX tradition? The limitation is due to the way in which the groups a *process* (not user) belongs to. When you log in, login/sshd/xdm/schroot or whatever process is controlling the process will call initgroups(3) to read the group database for the user in question, which internally calls setgroups(2) to add all of the GIDs in question to the process. It will then call setgid(2) and setuid(2) to drop privileges and then typically exec the login shell/command/ session as appropriate. Setting the group list with setgroups(2) requires the CAP_SETGID capability (i.e. root in almost all cases). Because root privileges are dropped, the group list is fixed and subsequently inherited by all child processes. This is why you need to log out and back in again, because it's only when you log in you can add the new group to the group list of the parent of your login session. > (I note that it seems > HAL makes an on-invocation group check for suspend so > adding a user to the powerdev group and attempting a > suspend from a pre-logged in session works) HAL is just querying the group database directly. Any process can of course do this. But it's asking a different question, namely: what groups is this user a member of in the group database. All of the system calls checking group membership are checking the process' group list, not the group database. This is because internally the group list is just a list of integer GIDs, so it's fast and does not require any database lookups (which are all done in userspace by libnss*). Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `- GPG Public Key: 0x25BFB848 Please GPG sign your mail.
Description: Digital signature