Re: Operator, Information, give me geom.ctl on the line

On Jul 28, 2026, at 2:57=E2=80=AFPM, Poul-Henning Kamp =
<[email protected]> wrote:
>=20
> I have been pondering this ticket for a couple of years:
>=20
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D277228
>=20
> The short version of the story is that:
>=20
> crw-r-----  1 root operator 0xa Jul 28 15:47 /dev/geom.ctl
>=20
> allows anybody in the operator group to issue ioctls, which, for
> instance, can nuke all partitioning from a disk.


$ git blame MAKEDEV| grep operator
0068854758b9d (Ralph Campbell   1985-03-02 00:43:33 -0800 184)          =
chgrp operator ${name}${unit}[a-h] r${name}${unit}[a-h]

Perhaps the operator group was added to allow mounting/unmounting
tapes or some such tasks? Better to ask the original author
(at least for the sake  of history).

> Kyle, Warner and I agree that:
>=20
> crw-r-----  1 root wheel 0xa Jul 28 15:47 /dev/geom.ctl
>=20
> Would make more sense, but we have no idea if, or to what extent,
> anything depends on operator issuing geom ioctls.

>=20
> The plan, such as it is, is to make that change in current to find =
out.
>=20
> Before I do that, I want to give any interested parties a chance to
> sandbox it for themselves, all you have to do edit geom_ctl.c
> and change:
>=20
> void
> g_ctl_init(void)
> {
>=20
> make_dev_credf(MAKEDEV_ETERNAL, &g_ctl_cdevsw, 0, NULL,
>    UID_ROOT, GID_OPERATOR, 0640, PATH_GEOM_CTL);
> }
>=20
> To GID_WHEEL instead.
>=20
> If I receive no emails indicating disasters, I will make the change in
> current in a couple of weeks, and wait for fireworks.
>=20
>=20
> The longer and slightly rambling version
> ----------------------------------------
>=20
> All the way back to 386BSD's /etc/MAKEDEV script, and probably prior =
to
> that, group operator had read-only access to disk devices:
>=20
>    fd*|wd*)
>            umask 2 ; unit=3D`expr $i : '..\(.*\)'`
>            case $i in
>            fd*) name=3Dfd; blk=3D2; chr=3D9;;
>            wd*) name=3Dwd; blk=3D0; chr=3D3;;
>            esac
>            case $unit in
>            0|1)
>                    mknod ${name}${unit}a   b $blk `expr $unit '*' 8 + =
0`
>                    [=E2=80=A6]
>                    chgrp operator ${name}${unit}[a-h] =
r${name}${unit}[a-h]
>                    chmod 640 ${name}${unit}[a-h] r${name}${unit}[a-h]
>=20
> My presumption, and Kirk can undoubtedly tell us more, is that this
> was about operators, of the kind who whizzed around on roller-skates
> on the raised floor tiles in computer rooms in the 1970ies and
> 1980ies, being able to make backups with dump(8) without being root.
>=20
> The important part is that group operator could not write to the =
disks,
> only read them, and since partition tables we written directly to
> raw disks, operators could not muck about with them.
>=20
> When I wrote GEOM, we accessed out-of-band and in-band partitioning
> information in really gross ways, and for some time backwards
> compatibility was required, and for specific reasons I no longer
> recall, geom.ctl got group operator, like the actual geom_disk
> devices did.
>=20
> The other half of the mess is that ioctl leaves access control to
> the eventual recipients of the requests, and they end up *all* over
> the kernel in many interesting and frankly disturbing ways, but
> almost always without access to the originating threads credentials,
> so more often than not, the check is "You're OK, because you obviously
> have an open FD".
>=20
> The third half of the mess is that there is no definition of what
> group=3Doperator is even supposed to mean:
>=20
>    critter phk> ls -l /dev/*ctl
>    crw-rw----  1 root operator 0x2b 28 Jul 15:47 /dev/apmctl
>    crw-------  1 root wheel    0x18 28 Jul 15:47 /dev/consolectl
>    crw-------  1 root wheel     0x9 28 Jul 15:47 /dev/devctl
>    crw-r-----  1 root operator  0xa 28 Jul 15:47 /dev/geom.ctl
>    crw-------  1 root wheel     0xb 28 Jul 15:47 /dev/mdctl
>    crw-r-----  1 root operator 0x68 28 Jul 15:47 /dev/mlx5ctl
>    crw-r--r--  1 root operator 0x43 28 Jul 15:47 /dev/usbctl
>=20
> There are 74 kernel source lines contain GID_OPERATOR plus,
> obviously a 75th line with the #define.
>=20
> If I try to summarize those 74 lines, it looks like the perception
> amongs kernel committers is something like "operator is allowed to
> mess with hardware except when they're not."
>=20
> If we take a clue from the recent "audio" and "video" groups,
> operator privilege should be broken down in more targeted groups
> (GID_USB, GID_SPI, GID_FIREWIRE, GID_...)
>=20
> But wait, shouldn't the first one be broken down into GID_USB_SERIAL,
> GID_USB_SCANNER, GID_USB_STORAGE, GID_USB_ETHERNET, GID_USB_BLUETOOTH,
> GID_USB_GSM, etc ?
>=20
> That way lies GID_BIKESHED.
>=20
> We also have devfs(8) and devd(8) now.
>=20
> Given that the vast majory of all FreeBSD systems are single user,
> or more likely "no-user", how many of them actually have any users
> in the "operator" group, besides "root" ?
>=20
> Hint: Not even freefall.
>=20
> Maybe GID_OPERATORs days have come and gone, so we should ?
>=20
> s/GID_OPERATOR/GID_WHEEL/

I'm not a fan of a kitchensink wheel. Would an operator group
as a readonly wheel be better?

Eventually may be move towards using capabilities but that
that is likely hard to do right....

>=20
> Poul-Henning
>=20
> (Who makes absolutely no apologies for the Subject line.)
>=20
> --=20
> Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
> [email protected]         | TCP/IP since RFC 956
> FreeBSD committer       | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by =
incompetence.

-- bakul