# Groups Overview



## jbo (Oct 3, 2021)

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?!


----------



## Geezer (Oct 3, 2021)

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.


----------



## T-Daemon (Oct 3, 2021)

jbodenmann said:


> I am particularly curious because after adding my user to the `operator` group I seem to be allowed to shutdown but not to reboot?!


/sbin/reboot is in the wheel group:

```
% ls -l /sbin/shutdown  /sbin/reboot
-r-xr-xr-x   4 root     wheel        10424  Apr      9 08:19 /sbin/reboot*
-r-sr-xr--   2 root     operator     15432  Apr      9 08:19 /sbin/shutdown*
```


----------



## kpedersen (Oct 3, 2021)

Some programs have the setuid bit set `+s` (Not to be confused with "sticky-bit", this is for retaining program in memory).


```
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.


----------



## zirias@ (Oct 3, 2021)

T-Daemon said:


> /sbin/reboot is in the wheel group:


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.


----------



## jbo (Oct 3, 2021)

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?


----------



## kpedersen (Oct 3, 2021)

jbodenmann said:


> 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


----------



## grahamperrin@ (Oct 3, 2021)

jbodenmann said:


> … 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_ …








						Understanding the 'staff' user group
					

It's known that all users are members of the 'staff' group. If you setup a standard user and create any file, a list of that file in the terminal with 'ls -la' shows the user group to be 'staff'.  ...




					apple.stackexchange.com
				




_operator_ is no longer a member of gid 20:


```
% 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:


```
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: 

<https://docs.freebsd.org/en/books/handbook/book/#_device_configuration>
<https://docs.freebsd.org/en/books/handbook/book/#virtualization-virtualbox-usb-support>
Hint:


```
% 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.


----------



## bakul (Oct 3, 2021)

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!


----------



## grahamperrin@ (Oct 3, 2021)

Thanks,



bakul said:


> 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:





– 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


----------



## bakul (Oct 3, 2021)

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.


----------



## dd_ff_bb (Oct 3, 2021)

Fun Fact:


```
# 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
```


----------



## Erichans (Oct 3, 2021)

bakul said:


> 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):

```
-n	     Whenever dump requires operator attention,	notify all operators
	     in	the group "operator" by	means similar to a wall(1).
```


----------



## dd_ff_bb (Oct 3, 2021)

Other than above, groups only have meaning with usage of below functions if i'm not mistaken:


```
setgid
getgid
setegid
getegid
setregid
setresgid
getresgid
issetugid
setgroups
getgroups
```


----------



## Erichans (Oct 3, 2021)

Zirias said:


> 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)):

```
-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):

```
-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):

```
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.


----------



## mark_j (Oct 3, 2021)

jbodenmann said:


> 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...


----------



## Erichans (Oct 3, 2021)

My emphasis added:


jbodenmann said:


> 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?


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.


----------



## zirias@ (Oct 4, 2021)

Erichans said:


> 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.


----------



## Jose (Oct 4, 2021)

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.


----------



## grahamperrin@ (Oct 5, 2021)

OT from groups, obscure discussion about shutdown and reboot: <https://forums.FreeBSD.org/threads/81237/post-522096>


----------

