I have run into the following problem: I have set up several UNIX groups (i. e. those in the /etc/group file) which my working account should be a member of. In fact, I wanted to set up a dedicated group for each major project I'm involved in. That way, all the people working together in some project can be made members of that group, using the group membership to control access to shared project resources without a requirement resort to using POSIX ACLs for that purpose (which are way too complicated for most casual users to comprehend - some of them even have a hard time understanding plain old chmod). Together with the many predefined groups (plugdev, users, audio, video, games, ...) this makes a considerable number of supplementary groups my account has to be a member of (30 or so). But the Linux kernel does not allow a single process, such as the login shell, to be a member of so many groups at a single instance in time. The kernel's group vector has a fixed size (some 20 groups I think), and it is not possible to be an active member of more groups at the same time. This is actually not a problem, because I can do a "newgrp" or "sg" when I need to activate a specific group while working on a specific project. There is no need to be an active member of all those groups at the same time. But there are some groups I always want to be a member of, for instance "wheel", "audio", "video" or "plugdev". The problem is that I could not find a way how to initialize the group vector to a known subset of all the supplementary groups I am a member of. Reproducible: Always Steps to Reproduce: 1.Be sure you are a member of most of Gentoo's predefined groups (audio, video, plugdev, wireshark, ...) 2. Add a few groups of your own, so that there are 25+ groups for you or so in /etc/group 3. Use "id" to check which groups are actually active for your account Actual Results: A random subset of groups is active, the others not. There seems to be no way to determine which groups are assigned when logging in (newgroup or sg has to be used to impersonate the other group's identities) Expected Results: There needs to be a PAM module or some other way in order to specify the supplementary groups which are most important and should always be loaded into the login process' kernel-maintained group vector. Or Gentoo should use less predefined groups for its purposes, so that this problem cannot happen as easily. Currently, when logging in, Linux assigns a seemingly random subset of the supplementary groups to the group vector, possibly not assigning important groups like "plugdev" or "video" once the group vector has reached its limit. So what I need is either some means of determining the order in which the kernel tries to assign the groups into the group vector, or some means how to explicitly select a subset of groups to be assigned to the group vector on login, skipping any remaining groups. I think it must be possible to use PAM somehow for this, but I was not yet able to find out how. However, with current Gentoo userland tools, I have been unable to accomplish this task.
>That way, all the people working together in some project can be made members of that group, using the group membership to control access to shared project resources without a requirement resort to using POSIX ACLs for that purpose (which are way too complicated for most casual users to comprehend - some of them even have a hard time understanding plain old chmod). But that#s the way to go, I'd say. Rolling a dice and assigning to base-system, please bear with me. ;)
i dont really see this as being a Gentoo-specific problem, nor a problem that has been addressed by any distro if it's to be addressed at the pam level, then it should be taken up with the pam maintainers ...
Update: When I tried to fix the problem myself by improving the current 2.6.24 kernel accordingly, it found out someone already did that for me! :-) The issue of a size-restrained supplementary group vector has been fixed in meantime by the kernel guys! There is no such limit any more; a process can now be member of an arbitrary number of supplementary groups at the same time. For the interested ones, there is still an internal table limit of about 20 supplementary groups in a fixed-size array of the kernel thread control block. If more than this number of supplementary groups is required for a process, memory for the group vector is allocated dynamically, and the beforementioned fixed-size array is no longer used. It should also be noted that the size of the group vector should not result in performance/scaling problems, because the kernel searches it with an O(log2) algorithm. The only actual overhead involved with a larger group vector is the additional dynamic allocation, but that's normally only done once when the process is created. Anyway, cheers to the kernel guys, and closing bug.
