[SOLVED] Where is information on group membership stored apart from /etc/groups?

hazel · 05-24-2019, 11:10 AM

I have found a weird discrepancy in my Slackware system. If I run the groups command on myself, I get the following string of groups:

hazel lp wheel floppy audio video cdrom scanner

However, if I look in /etc/groups, I can see myself only in wheel, audio, video and scanner. These are the groups to which I added myself using vigr. I have no particular wish to be a member of floppy or cdrom (who uses floppies these days?), but why does the system think I am? Incidentally, the kernel does not seem to honour these extra groups; for example I was not able to contact the pulseaudio daemon until I added myself by hand to the audio group even though at the time, groups said I was already a member. That was what alerted me to the problem.

If I su to myself, I get only my primary group plus the groups specified in /etc/group. Clearly su is checking the /etc/groups file. But where does the login command get its group info from?

Also I should like to know where group information is stored for the session. I know it must be stored somewhere because adding someone to a group is not retrospective; the user has to su or logout/login to pick it up. An environmental variable would seem the logical place but I can't see one for groups, only LOGNAME for the user name.

thinknix · 05-24-2019, 02:16 PM

Groups gets the info from /etc/group, but if you have made changes in your current shell session they will not be reflected until you logout and login again. From https://www.gnu.org/software/coreuti...ps-invocation:

Quote:

Primary and supplementary groups for a process are normally inherited from its parent and are usually unchanged since login. This means that if you change the group database after logging in, groups will not reflect your changes within your existing login session.

So I suspect that you just need to logout/login again to get the updated group perms.

cwizardone · 05-24-2019, 02:32 PM

From the Slackware Linux CD-ROM Installation HOWTO:

Quote:

......To make an account for yourself, use the 'adduser' program. To start it,
type 'adduser' at a prompt and follow the instructions. Going with the
default selections for user ID, group ID, and shell should be just fine
for most users. You'll want to add your user to the cdrom, audio, video
plugdev (plugable devices like USB cameras and flash memory), scanner, and
lp groups if you have a computer with multimedia peripherals and want to
be able to access these. Add these group names at the following prompt:

Additional groups (comma separated) []:

To add the user to all the recommended user groups automatically, hit the
up arrow at this prompt to fill them in, and then hit enter......

scasey · 05-24-2019, 02:48 PM

Interesting. I see an variable in the output of set

Code:

GROUPS=()

Which, I'm guessing, holds the current session's group information. It displayed its contents one time, after I ran the id command, but I can't seem to repeat that now. I think it looked like this:

Code:

GROUPS=([0]="0" [1]="27")

which are the group ids of the groups to which I belong -- and are output by the id command with no options.

So, hazel, I suspect that's where the groups are stored for the session.

thinknix · 05-24-2019, 03:33 PM

I think we're talking about a few different things - group permissions are really associated with processes which run under the real group ID and supplemental group IDs of the currently logged-in user. Initially (at login time) the primary and supplemental group IDs are fetched from the groups database, which could be /etc/group, or LDAP, or some other database.

After that, any process spawned by that user inherits the same exact primary and supplemental group data (this would include a new bash terminal, which uses the parent processes' stored group data to populate the GROUPS shell variable when it starts). When you try to access a file owned by a particular group, the kernel checks against the group data stored in the calling process, it doesn't fetch it from /etc/group every time. So that explains why you have to logout/login again when you edit /etc/group - and for most of us on graphical desktops - it means logging out of the X session. Just starting a new terminal window won't work, because the parent process still has the old group data.

To go back to the original question - the 'groups' command in GNU coreutils grabs the group data from the current process if you don't supply a username argument, not directly from /etc/group. If you specify a username, it will grab data from /etc/group, which is more accurate but won't help you as far as permissions. You still have to logout/login again to get updated group access permissions.

hazel · 05-25-2019, 07:50 AM

I think the first two answers have missed the problem. Here is the output of the groups command

Code:

 groups
hazel lp wheel floppy audio video cdrom scanner

And here is the information from /etc/groups

Code:

 grep hazel /etc/group
lp:x:7:lp,hazel
wheel:x:10:root,hazel
audio:x:17:root,pulse,hazel
video:x:18:hazel
scanner:x:93:hazel
hazel:x:1000:

Clearly there's a discrepancy here and I want to know where it comes from. I can understand that I have not been added to the hazel group, because that is my primary login group which is already registered in /etc/passwd. But, according to the /etc/group file, I'm not in the floppy or cdrom groups either, and I wasn't in the audio group until I put myself in by hand, yet the groups command thinks otherwise.

Clearly then, my original login (the parent process of the session) did not get the information about group membership from /etc/groups, so where does it come from?

I can now at least answer my second question: during the session, the group list is stored in a specific field in the kernel's task structure for a process. I was able to retrieve it by using cat /proc/<pid>/status. Presumably it is handed down to a forked child automatically. But this list includes the extra groups that I should not be a member of. Where do they come from?

hazel · 05-25-2019, 09:13 AM

Found it! There's an entry in /etc/login.defs which adds extra groups.

Code:

# List of groups to add to the user's supplementary group set
# when logging in on the console (as determined by the CONSOLE
# setting).  Default is none.
#
# Use with caution - it is possible for users to gain permanent
# access to these groups, even when not logged in on the console.
# How to do it is left as an exercise for the reader...
#
# Most of these groups are self-explanatory, but in the case of
# "lp", it is because group lp is needed to use a scanner that
# is part of a multifunction printer.
#
# Note that users are added to these default groups only when
# logging into a shell with /bin/login, not when using a login
# manager such as kdm.  In that case, users who should have
# hardware access must be added to the appropriate groups
# when the user is added with adduser or useradd, or by editing
# /etc/group directly, preferably using "vigr"
#
CONSOLE_GROUPS         floppy:audio:cdrom:video:lp:scanner

Clearly it is only login which uses these defaults, not su. So when I su to myself, I get only the groups from /etc/group.

I'm going to reset this variable to null. I don't like things being done behind my back (senile paranoia

)