Groups Overview

jbo@

Developer
I seem to fail at finding documentation regarding the "default", "built-in" or common user groups. Could somebody point me towards the right direction?

The reason I'm asking this is because I came across the operator group when setting up a FreeBSD desktop machine. I have not encountered this group before (at least not directly). From what I understood, the idea is to give members of the operator group access to some system relevant aspects such as ACPI, shutdown, USB hot-pluging and similar. But as mentioned I couldn't find the actual documentation on this.

I am particularly curious because after adding my user to the operator group I seem to be allowed to shutdown but not to reboot?!
 
Being part of operator does allow you to reboot with shutdown -r +whenever

And you are right, I don't to know how I know this. I suppose you have to be in the intheknow group too.
 
Some programs have the setuid bit set +s (Not to be confused with "sticky-bit", this is for retaining program in memory).

Code:
stat /sbin/shutdown
1024 2229174 -r-sr-x--- 1 root operator 8927616 275928 "Oct  2 23:37:11 2021" "Oct  4 23:47:29 2020" "Mar  6 13:47:57 2021" 16384 576 0 /sbin/shutdown

In this example above, the program is chmod g+s and the owner group is operator. This means when someone in that group runs the program, their effective ID is changed into the owner user (root). This then has enough privileges to perform the shutdown.

You will also see some files in /dev set so that operater has +w privileges.

So really it is just a way of carrying out common tasks without needing su, doas or sudo.
 
Thank you for all the information!

Would somebody be able to locate the corresponding documentation of these user groups? Or do you guys all just know and there's no documentation and I'm now joining the circle of "just knowing" essentially deferring the problem to the next poor guy running into this question? :D
 
Would somebody be able to locate the corresponding documentation of these user groups?
Urm, I can't quite recall where I leaned about this stuff to be honest.

I think it was "on the job" with a tiny book (https://www.oreilly.com/library/view/linux-pocket-guide/9780596806347/).

The suidbit stuff again was learned as and when I needed it to solve some IPC issues with a desktop environment I was writing a number of years back.

As for FreeBSD specific groups, the handbook at least used to mention this stuff in the user account creation section: https://docs.freebsd.org/en/books/handbook/basics/#users-synopsis
 
… documentation of these user groups? …

Not the answer that you want, but (particularly for people who have/had a Mac background) it's interesting to note how things have changed over time.

In 1993 <https://cgit.freebsd.org/src/commit/?id=9319cacfd5b6133b1278537a26eb6579cc6a1497> operator was moved from gid 28 to gid 20; gid 20 is memorably staff

operator is no longer a member of gid 20:

Code:
% id -G operator
5
% pw groupshow -g 5
operator:*:5:root,grahamperrin,bbsadmin-l
% pw groupshow -g 20
staff:*:20:
% pw groupshow -g 28
pw: unknown gid `28'
% uname -KU ; freebsd-version -kru ; date
1400033 1400033
14.0-CURRENT
14.0-CURRENT
14.0-CURRENT
Sun  3 Oct 2021 16:09:49 BST
%

A better understanding of the current roles of the operator user and the operator group may be gained through use of find(1) or sysutils/bfs.

Here, for example:

Code:
root@mowa219-gjp4-8570p-freebsd:~ # bfs / -user operator -print
bfs: error: /proc/20016: No such file or directory.
bfs: error: /proc/20015: No such file or directory.
/var/db/entropy
^C
root@mowa219-gjp4-8570p-freebsd:~ # bfs / -group operator -print
/etc/dumpdates
/sbin/shutdown
/sbin/mksnap_ffs
/sbin/poweroff
/dev/cuse
/dev/geom.ctl
/dev/acpi
/dev/apmctl
/dev/apm
/dev/zfs
/dev/usbctl
/dev/xpt0
/dev/mlx5ctl
/dev/pass0
/dev/pass1
/dev/pass2
/dev/ses0
/dev/cd0
/dev/ada0
/dev/ada0p1
/dev/ada0p2
/dev/ada0p3
/dev/ada0p3.eli
/dev/pass3
/dev/da0
/dev/da0p1
/dev/pass4
/dev/da1
/dev/da1p1
/dev/pass5
/dev/da2
/dev/da2p1
/dev/fuse
/dev/ada0p2.eli
/dev/usb/0.1.0
/dev/usb/1.1.0
/dev/usb/2.1.0
/dev/usb/0.1.1
…

– and so on, hier(7) should help to understand the purposes of some paths.

Results from <https://www.google.com/search?channel=nrow5&q=operator+group+site:docs.freebsd.org&tbs=li:1#unfucked> lead indirectly to these points (probably more) within the full FreeBSD Handbook:
Hint:

Code:
% pkg info --list misc/freebsd-doc-en | grep book | grep pdf
        /usr/local/share/doc/freebsd/en/books/arch-handbook/book.pdf
        /usr/local/share/doc/freebsd/en/books/design-44bsd/book.pdf
        /usr/local/share/doc/freebsd/en/books/dev-model/book.pdf
        /usr/local/share/doc/freebsd/en/books/developers-handbook/book.pdf
        /usr/local/share/doc/freebsd/en/books/faq/book.pdf
        /usr/local/share/doc/freebsd/en/books/fdp-primer/book.pdf
        /usr/local/share/doc/freebsd/en/books/handbook/book.pdf
        /usr/local/share/doc/freebsd/en/books/porters-handbook/book.pdf
%

Also/alternatively localised misc/freebsd-doc-fr, misc/freebsd-doc-de et cetera.
 
The "operator" entry seems to have first appeared in 4.3BSD (June 1986) /etc/passwd. Back when Unix workstations were still not common and shared Unix systems had real operators and all! Since it is not in 4.2BSD I imagine there may have been some unfortunate incident which resulted in this addition! If you want to go down this rabbit hole, there is always Prof. Diomidis Spinnellis' reconstructed Unix repo on github!
 
Thanks,

The "operator" entry seems to have first appeared in 4.3BSD (June 1986) /etc/passwd. …

The Design and Implementation of the 4.4BSD Operating System (published by the FreeBSD Foundation) – no mention of operator, unfortunately.

Foundation publications aside, from a more recent well-known book:

1633277796848.png

– Absolute FreeBSD, 3rd Edition (Michael Warren Lucas) <https://mwl.io/nonfiction/os#af3e>

Absolute FreeBSD, 3rd Edition: The Complete Guide to FreeBSD - Michael W. Lucas - Google Books
 
UTSL! Fetch the following rootdump, uncompress and extract etc/passwd from it and grep for operator.
ftp://ftp.math.utah.edu/pub/mirrors/minnie.tuhs.org/old/4BSD/Distributions/4.3BSD/rootdump.gz
You can poke around various unix distributions and see how things evolved.

As to the omission, my guess is that the 4.4BSD book may have borrowed material from The Design and Implementation of the 4.3 BSD UNIX Operating System (1989) and the operator user was added late in the game, after the material for the 4.3BSD book was researched.
 
Fun Fact:

Code:
# dmesg
                                                                                                                                                                           
Oct  2 10:13
4.3 BSD Quasijarus UNIX #3: Sat Feb 14 20:31:03 PST 2004
    root@luthien.Harhan.ORG:/nbsd/usr/src/sys/GENERIC
real mem  = 16744448
SYSPTSIZE limits number of buffers to 112
avail mem = 14920704
using 112 buffers containing 917504 bytes of memory
MicroVAX 3000, ucode rev 6
tmscp0 at uba0 csr 174500 vec 774, ipl 15
tms0 at tmscp0 slave 0
tms1 at tmscp0 slave 1
uda0 at uba0 csr 172150 vec 770, ipl 15
uda0: version 3 model 3
uda0: DMA burst size set to 4
ra0 at uda0 slave 0: ra82, size = 1216665 sectors
dz0 at uba0 csr 160100 vec 300, ipl 17
dz1 at uba0 csr 160110 vec 310, ipl 17
dz2 at uba0 csr 160120 vec 320, ipl 17
dz3 at uba0 csr 160130 vec 330, ipl 17
Changing root device to ra0a
WARNING: clock gained 111 days -- CHECK AND RESET THE DATE!
#
#
# cat /etc/passwd
root::0:0:System Manager:/:/bin/sh
daemon:*:1:31:System &:/:
operator:*:2:28:System &:/:/bin/sh
bin:*:3:10:System Binaries:/:
games:*:7:2:Games pseudo-user:/usr/games:
uucp:*:66:1:UNIX-to-UNIX Copy:/usr/spool/uucppublic:/usr/lib/uucp/uucico
nobody:*:32767:32767:Unprivileged user:/nonexistent:/dev/null
#
#
# cat /etc/group
wheel:*:0:root
daemon:*:1:daemon
kmem:*:2:root
sys:*:3:root
tty:*:4:root
operator:*:5:root
bin:*:10:root
guest:*:31:root
ingres:*:74:ingres
nobody:*:32767:nobody
#
# find / -user operator -print
/etc/dumpdates
#
# find / -group operator -print
/etc/shutdown
/etc/disklabel
/bin/df
/dev/hp0a
/dev/hp0b
####i omitted other dev devices.....
#
# whereis shutdown
shutdown: /usr/src/etc/shutdown.c /etc/shutdown
# ls -alg /etc/shutdown
-rwsr-x---  1 root     operator    28672 Dec  5  2003 /etc/shutdown
#
# ls -alg /etc/reboot
-rwxr-xr-x  1 bin      bin         25600 Dec  5  2003 /etc/reboot
#
# df
Filesystem    kbytes    used   avail capacity  Mounted on
/dev/ra0a       7093    5229    1154    82%    /
/dev/ra0h     136504       1  122852     0%    /home
/dev/ra0g     394851   71691  283674    20%    /usr
 
The "operator" entry seems to have first appeared in 4.3BSD (June 1986) /etc/passwd. Back when Unix workstations were still not common and shared Unix systems had real operators and all!
I think there's some history behind this indeed. IIRC, an operator (=the human) had once a very a distinct and precise job description.

Operators performed administrative jobs that need elevated privileges for low level access, but they are not almighty: more specifically they can't get elevated to root privileges such as su. In light of keeping the system operational which necessitates their (low level) systems accesses, they are usually very much monitored. That aspect can't be changed in a well setup system. As root (or member of the wheel group) you can circumvent such monitoring/logging actions, because, well, you're the root.

As to the division between which commands are enabled for the operator group and which for the wheel group, those have probably arisen from historical context; I am not familiar with those details.

Some context for the operator group:
Practical UNIX and Internet Security, 3rd Edition; 5.1.3 Groups and Group Identifiers (GIDs):
Groups can also be used to restrict access to sensitive information or specially licensed applications to a particular set of users: for example, many Unix computers are set up so that only users who belong to the kmem group can examine the operating system's kernel memory. The operator group is commonly used to allow only specific users to run the tape backup system, which may have "read" access to the system's raw disk devices.

Mastering FreeBSD and OpenBSD Security; see section Filesystem access:
On a typical server (either OpenBSD or FreeBSD), the raw disk devices are owned by root, but the group operator has access to read them. This allows the operator group to bypass the filesystem and its permissions and read raw data blocks from the disk. This is how dump is able to take a near image of a disk device. If you rebuild a filesystem with newfs(8) and then restore your files, the files will be restored almost exactly, down the inode numbers in many cases. The operator group is especially designed for backups this way. If you look in /dev, you will find that operator has read access to almost all significant raw data devices: floppy disks, hard drives, CD drives, RAID controller devices, backup tape drive devices, etc. Furthermore, the operator user’s account is locked down in a way that the user cannot log in. If you run backups, either by custom scripts or by Amanda, you should use the operator user and/or group.

Absolutely FreeBSD 3rd edition by M.W. Lucas; Table 9-1, p. 185
operator - Users that can access drives, generally for backup purposes
wheel - Users who may use the root password

So, activities beholden to the operator group seem to be linked for a large part to backup activities, as for example also indicated by dump(8):
Code:
-n	     Whenever dump requires operator attention,	notify all operators
	     in	the group "operator" by	means similar to a wall(1).
 
Last edited:
Other than above, groups only have meaning with usage of below functions if i'm not mistaken:

Code:
setgid
getgid
setegid
getegid
setregid
setresgid
getresgid
issetugid
setgroups
getgroups
 
Which makes sense because it reboots without giving rc a chance to cleanly stop services, so you should only ever use it in case of emergency (like halt as well).

shutdown(8) is the command to use for clean halting and rebooting.
Could you elaborate?

I may be missing something but, I see in shutdown(8), halt(8) or reboot(8) two options, namely (see halt(8) & reboot(8)):
Code:
-N The file system cache is not flushed during the initial process
   clean-up, however the kernel level reboot(2) is still processed
   with a sync.  This option can be useful for performing a
   "best-effort" reboot when devices might be unavailable. This can
   happen when devices have been disconnected, such as with
   iscsi(4).

-n The file system cache is not flushed. This option should proba-
   bly not be used.
whereby halt reboot execute in a less graceful manner (-N) and a not graceful manner (-n). The same for the option at the shutdown(8):
Code:
-n If the -o option is specified, prevent the file system cache from
   being flushed by passing -n to halt(8) or reboot(8). This option
   should probably not be used.

Otherwise all seem to perform pretty much the same function with respect to closing down gracefully, except of course for the reason mentioned by shutdown(8):
Code:
     Normally, the shutdown(8) utility is used when the	system needs to be
     halted or restarted, giving users advance warning of their impending doom
     and cleanly terminating specific programs.

I see the same in Absolutely FreeBSD 3rd edition by M.W. Lucas; System Shutdown, p. 74
When you shut down FreeBSD with the shutdown(8), halt(8), or
reboot(8) commands, the system calls the shell script /etc/rc.shutdown.
This script calls each rc.d script in turn with the stop option, reversing the
order they were called during start-up, thereby allowing server programs to
terminate gracefully and disks to tidy themselves up before the power dies.
 
I seem to fail at finding documentation regarding the "default", "built-in" or common user groups. Could somebody point me towards the right direction?

The reason I'm asking this is because I came across the operator group when setting up a FreeBSD desktop machine. I have not encountered this group before (at least not directly). From what I understood, the idea is to give members of the operator group access to some system relevant aspects such as ACPI, shutdown, USB hot-pluging and similar. But as mentioned I couldn't find the actual documentation on this.

I am particularly curious because after adding my user to the operator group I seem to be allowed to shutdown but not to reboot?!
Groups are inherently what you want the them to be. Assign a group to a file, that's it.
To find all the operator controlled files: find / -group operator

I think the operator comes from the use of operators in ye olde computer rooms where they would load tapes, run jobs, shutdown sub-systems etc.

BTW I look at half the groups in the groups file and wonder what their use-case is...:)
 
My emphasis added:
Thank you for all the information!

Would somebody be able to locate the corresponding documentation of these user groups? Or do you guys all just know and there's no documentation and I'm now joining the circle of "just knowing" essentially deferring the problem to the next poor guy running into this question? :D
I guess you mean other groups as listed in the message above by grahamperrin. Of those, as far as I know and besides the operator group, only the wheel group in a standard FreeBSD has a predefined important capability with respect to the possibility to su to root. This can be changed, see su(8) and pam group(8). The name wheel has its origins in the TENEX OS:
TENEX was an operating system developed in 1969 by BBN for the PDP-10, which later formed the basis for Digital Equipment Corporation's TOPS-20 operating system.
The origins of the name of the wheel group lie in the wheel-bit, from A Guide to the World of Computer Wizards:
WHEEL noun.
1. A "privilege" BIT that, when set, CANONICALLY allows the possessor to perform any operation whatsoever on a timesharing system, such as read or write any file on the system regardless of protections, change or look at any address in the running monitor, CRASH or reload the SYSTEM, and kill or create jobs and USER accounts. The term was invented on the TENEX operating system and carried over to TOPS-20 and others. See TWENEX.
2. A person who possesses a set wheel bit (and who therefore has great privilege and power on that system). "We need to find a wheel to unwedge the hung tape drives".

WHEEL WARS. A period during which student wheels HACK each other by attempting to log each other our of the system, delete each other's files, or otherwise wreak havoc -- usually at the expense of the lesser USERS.
 
Could you elaborate?
I didn't talk about flushing, this is a different (and more low-level) topic, but about cleanly stopping services. halt and reboot send out SIGTERM, which at least gives the running process a change to clean up, but the init-script doesn't get a chance. At least, that's what I found written multiple times on these forums (and it would explain my own experience of NOT seeing init-script output when using halt or reboot directly).

But it would contradict the book quote you added.

edit: Browsing the source (in doubt, the definitive truth), I couldn't find proof rc scripts are only handled by shutdown so far 🤔 (but don't have time to read every single line right now). What can be confirmed quickly is that shutdown wraps the other tools and adds functionality. So in any case, it makes sense to allow operators only the more graceful/generic tool.
 
With all due respect to Mr. Lucas, it's actually init(8) that calls /etc/rc.shutdown. Start reading the man page at
When shutting down the machine, init will try to run the /etc/rc.shutdown
script. This script can be used to cleanly terminate specific programs
such as innd (the InterNetNews server). If this script does not termi-
nate within 120 seconds, init will terminate it. The timeout can be con-
figured via the sysctl(8) variable kern.init_shutdown_timeout.

Every process in a non-systemd Unix work-alike is a child or grand(+)child of init, which always runs with a PID of 1.

Interestingly, the original meaning of SIGHUP was "terminate". It was what happened if your serial line to the minicomputer hung up. I guess the idea was init would re-start the process, and thus it was a handy way to get it to re-read its configuration file. This side-effect is now the main meaning of HUP. Signals are described in the signal(3) man page.
 
Back
Top