For various reasons I was looking for an overview of the default groups in recent versions of slackware. Groups seems to divide into three categories, 1) dedicated to some daemon(s) e.g. apache, nogroup 2) access control to some file(s) through sgid binaries, e.g. slocate, utmp, and 3) general access control for users, e.g. video, plugdev (and 4) historical, basically defunct groups). But it's not necessarily clear which groups are suitable for users to belong to. So, not finding any coherent overview, I tried my best to figure out what the different groups are actually for. This is the list I've compiled, any further insight is welcomed (especially regarding mem, pop, oprofile, power and console).

bin:x:1:root,bin
Owner of some seemingly random files, such as /bin/rzip, /usr/bin/dv42_*, /usr/bin/elvis, /usr/include/gdbm.h. Once upon a time there probably was some good reason for this. But there seems to be no difference whether you're a member or not.

daemon:x:2:root,bin,daemon
User for at(1), owns /var/spool/at* and /etc/at.deny. I'm assuming some other third party unprivileged daemon might be configured to run as this user/group.

sys:x:3:root,bin,adm
Owner of some sound-related devices, /dev/null, /dev/zero et.c. in the a/devs-package (but not under udev). Also group owner of /var/run/cups/certs. Historical relic, I suppose.

adm:x:4:root,adm,daemon
Does not own any files (or devices). Historically allowed to read logs in /var/log^W/var/adm IIRC.

tty:x:5:
Ownes /dev/tty* and such, wall(1) and write(1) SGID to allow messaging to other users. Users should not be members of this group.

disk:x:6:root,adm
Members has R/W access to disk devices.

lp:x:7:lp
Can write to printer devices, has access to some cups files. Users logged in on the console becomes member in accordance with /etc/login.defs (same thing for the floppy, audio, video, cdrom and scanner groups).

mem:x:8:
?

kmem:x:9:
Members can read /dev/{kmem,mem,port}. Few users have legitimate reasons for being members.

wheel:x:10:root
Not owner of anything, not actually used by default. Typically used for users allowed to su (to root) or similar, by way of /etc/suauth, /etc/sudoers, changing permissions on /bin/su, (PAM,) et.c.

floppy:x:11:
Has access to floppy devices. (And ownes some files in /usr/bin from the a/floopy package.)

mail:x:12:mail
User/group for procmail (and other mail related things?) Owns /var/spool/{mail,mqueue}, binaries for procmail are SGID mail. Users should not be members.

news:x:13:news
Owner of vaious newsreader related files (including some man pages). Not for users to be member of, I believe.

man:x:15:
Does not seem to be used for anything. (I have some recollection of a /usr/bin/man being SGID to man for creation of cat pages in /var/man/cat[0-9] on some system, but those are owned by root.root in slackware by default.)

dialout
udev seems to be instructed to chown various serial and modem devices to dialout, (the same static device files from devs package are owned by the uucp group). For users who should have access to such devices.

audio:x:17:
Group members have access to audio devices in /dev.

video:x:18:
Members are allowed access to video devices in /dev. (Note to users of nvidia's binary blob: when nvidia.ko is modprobed, the associated device nodes are set world writable. Putting "options nvidia NVreg_DeviceFileUID=0 NVreg_DeviceFileGID=18 NVreg_DeviceFileMode=0660" in modprobe.conf would probably help if you're having trouble with non-video-members exploiting unpatched privilege escalation bugs in the driver...)

cdrom:x:19:
Members who should have access to read or burn various optical devices.

games:x:20:
Ownes /dev/djs[0-4] in the devs package. I would've though it had some relationship to the bsd-games package, but they appear to have no such connection. Also not mentioned in the udev configuration, I assume most joysticks are handeled similarly to other input devices.

slocate:x:21:
The database in /var/lib/slocate is owned by this group, and /usr/bin/slocate is SGID, so that users can't find others files.

utmp:x:22:
Some helper binaries are SGID, to be able to write to /var/log/wtmp and /var/run/utmp.

smmsp:w
User/group for sendmail.

tape:x:26:
Tape devices should be chown'ed to this group by udev. (I don't have any such devices, so I can't verify, but group membership is likely needed to read or write to tape drives.)

mysql:x:27:
User/group for mysql.

rpc:x:32:
User/group for NFS stuff.

sshd:x:33:sshd
User/group used for privilege separation by sshd. (Unrelated to the optional "AllowGroups" setting in sshd_config.)

gdm:x:42:
Pure legacy? /var/lib/gdm used to be owned by this group, when gnome was shipped with slackware.

shadow:x:43:
Has read access to /etc/{g,}shadow, for access by SGID binaries: xscreensaver and xlock.

ftp:x:50:
Group for anonymous ftp with proftpd. (See /etc/ftpusers.)

oprofile:x:51:
?

apache:x:80:
User/group for apache to run as.

messagebus:x:81:
User/grup that dbus runs as.

haldaemon:x:82:
I'm assuming hal used to run as this user/group.

plugdev:x:83:
Members are given access to pluggable devices by udev.

power:x:84:
Is one of the groups that is suggested for new users by adduser(8). No idea what is actually does.

netdev:x:86:
Members are given access to rfkill switches.

pop:x:90
I could not find any references to this user or group in /etc or /lib/udev, and it ownes no files.

scanner:x:93:
Legacy (?) group for access to scanner devices. According to the changelog for 14.0, the lp group is used instead.

nobody:x:98:nobody
nogroup:x:99:
Surprisingly, a few files are owned by these. /etc/openvpn/{certs,keys} and /var/db/proftpd. I was under the impression that no{body,group} were for daemons that didn't need access to any particular files.

users:x:100:
Umbrella group for regular users.

console:x:101:
?

Arch had a good write up here: https://wiki.archlinux.org/index.php/users_and_groups

Some of deprecated groups like log, ssh, or any other non-canonical groups can be used with certain tools for effective permission setting.

If you use process state changing software, you can run software as a certain users through groups and users very effectively. Runit, for example, uses a tool called chpst for this purpose.

The ssh group was one of the reasons I was interested in the topic. After unsuccessfully trying to ssh into an old machine, where I had apparenly added myself to the sshd group, since there was no ssh group defined in stock slackware.

I had also stumbled upon the archwiki page, however, there seems to be some discrepancies between arch and slack. The arch wiki mentions rfkill whereas we have netdev in slackware, and uucp vs dialout, dbus vs messagebus, log vs adm, optical vs cdrom, etc.
But, at least it pointed me towards the right direction about the power group (right to use pm-utils, according to the arch wiki). Even though no files are owned by the group, members should be allowed to power off and such from modern DEs. Which used to be done through HAL, but I can't be bothered to figure out exactly which FD.o kit handles such things in slackware today, (it has apparently been deprecated in favor of systemd in arch). I guess there's some black magic related to plugdev (and possibly other groups) lingering in some xml file as well. There seems to be a lot more involved in understanding all the groups, than simply greping /etc, /lib/udev and the MANIFEST.bz2 file.

rpc:x:32:
User/group for NFS stuff.

No - it is for remote procedure calls, which is how NFS happens to be implemented, but it isn't limited to just NFS.

There is also a "nfsnobody:x:65534" which should have no users. It is used by NFS when there is an unidentified GID in the NFS traffic. This is also in (or should be) the passwd file for the same reason (unidentified UID in the NFS traffic).

Members of the group sys used to be able to shutdown/reboot the system without requiring root. It may also have been used for network control, but I'm not certain about that.

There was a time when mem granted access to physical memory (via /dev/mem). In the really early days of UNIX this could be used to access device control registers external to the operating system. kmem granted access to the kernel memory as mapped by the kernel MMU tables (named /dev/kmem). This use doesn't really exist in Linux. And NO users should be in kmem. This USED to be how the "ps" utility accessed kernel tables, but all such usage has now been replaced with /proc.

tape:x:26:

I vaguely remember the tape group was used (UNIX days mind) to allow access to tape librarians for the purpose of debugging/entering tapes, tape database maintenance. It may have been used to communicate with operators to get the right tape mounted (manually) and to allocate/request allocation of tape devices for exclusive use by a user.

oprofile... See http://www.kodkast.com/unix-command/oprofile for details. I think this granted access to the device driver that is related. This might now be historical only, but it was supposed to work on the Linux 2.6 kernel.

news - this (and a news passwd entry) were used for running internet news service. As I recall (having been an INN news admin) only the server used the uid and group to control file ownership. Users read news via a tool which would connect to the news server to download files. Internet news worked very much like email, with the difference that news used a single shared storage for all users (though there could be user subscription lists).

console - I THINK this was used like the dialout group is now, but it was to grant access to a console tty (when the console actually was a serial device). This would again be a very old UNIX convention...

1 members found this post helpful.

That may be an implementation specific detail. All the NFS setups I've encountered have just used the normal 'nobody' user (which is what the LSB specifies for NFS, although even that is in the "optional" section.)

Not exactly - the value used (35534) is a 16 bit number (-2), possibly for old clients (that part I'm not sure). It was used for NFSv2. NFS v4 does/can use the other. You also see it in the idmap.conf manpage, which allows it to use any designated UID for "nobody".

The main advantage of nfsnobody is that it keeps the possibility of services that use "nobody" for other things separate from what NFS uses it for. With NFS it is specifically for "no such user". Services may run as the user/group "nobody" to prevent any unintentional file access. Using the same "nobody" for NFS COULD grant such file access.