There is a discrepancy between supplementary groups given via `groups` (or `id -Gn` which is equivalent according to the info file) and the contents of /etc/group, and by extension the contents of /etc/gshadow. There are several of my supplementary groups in which I do not appear in /etc/group.

Where does `groups` get its information from?

Taking a guess, I suspect that adding supplementary groups via usermod -aG does not correctly update /etc/groups.

I discovered this when trying to find out why sound in a script would not work when run via the "at" daemon. Running the script directly would play the sound fine. It turned out that, notwithstanding anything `groups` would tell me, I was not listed as a member of audio in /etc/group. Adding myself to audio via gpasswd added me to audio in /etc/group and had the side effect of also updating /etc/gshadow.

Have a look in /etc/login.defs; there's a list of groups and a good explanation there.

Lyle.

1 members found this post helpful.

Something you ought to know is, from the manual page for gpasswd,
Basically, you don't want to fiddle with group passwords 'cause you can create a mess without really trying.

The "better" way to add a group to a given user account is the usermod utility (and you need to be careful with it, too:
is the proper syntax to use to append group(s) to a userid.

There really isn't a good reason to use group passwords in virtually all normal operations; for what it's worth, I've never, in over 30 years of working with Unix/Linux systems, needed to use group passwords (been there, did that, didn't like it, undid it and stopped doing again).

In a normal (whatever normal may be) Slackware installation a user would need to be in these groups:
In the above, scanner, vboxusers and cvs are added for (1) an all-in-one printer, (2) VirtualBox and (3) CVS. Other than those, this list should be complete. There would be added with
Hope this helps some.

Thanks for the comment. I'm not using gpasswd to set up group passwords, just to add a user to a group. The Linux man page for gpasswd almost implies that setting a password is only a supplementary feature of gpasswd, the way I read it anyway.

I did discover vigr from reading login.defs, which I had not heard of before.

It seems to me that the implementation of logins.defs is broken if a user's sub-shells don't inherit the user's full set of supplementary groups including those in login.defs.

I wrote a blog post about my trouble with sound in the sub-shell created by "at". It was caused by the sub-shell's user not being a member of audio group.

If you add your users in the recommended way with the adduser script (not useradd) then it'll add all the appropriate groups for audio and suchlike for you (you have to press up-arrow at the appropriate point. It's mentioned in the on-screen instructions, but people tend to skip-read and miss it.

I tend to agree that the CONSOLE_GROUPS option in login.defs is probably only confusing matters and has little if any value these days. I wouldn't go so far as to say it's broken though.


BTW, the -a (append) option on usermod was only added on a recentish version of pkg-shadow so on older versions of Slackware you had to use "gpasswd -a" to add users to additional groups. Despite what tronayne said above, there's nothing wrong with using gpasswd for this, and I still believe it's the safer way to do this than usermod. I also disagree with his warning about group passwords, When used in the appropriate situation I see no problem with them. The warning on the man-page is simply the usual one about the weaknesses inherent in any shared-password scheme.

1 members found this post helpful.