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

I have been pondering this ticket for a couple of years:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277228

The short version of the story is that:

	crw-r-----  1 root operator 0xa Jul 28 15:47 /dev/geom.ctl

allows anybody in the operator group to issue ioctls, which, for
instance, can nuke all partitioning from a disk.

Kyle, Warner and I agree that:

	crw-r-----  1 root wheel 0xa Jul 28 15:47 /dev/geom.ctl

Would make more sense, but we have no idea if, or to what extent,
anything depends on operator issuing geom ioctls.

The plan, such as it is, is to make that change in current to find out.

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:

	void
	g_ctl_init(void)
	{

		make_dev_credf(MAKEDEV_ETERNAL, &g_ctl_cdevsw, 0, NULL,
		    UID_ROOT, GID_OPERATOR, 0640, PATH_GEOM_CTL);
	}

To GID_WHEEL instead.

If I receive no emails indicating disasters, I will make the change in
current in a couple of weeks, and wait for fireworks.


The longer and slightly rambling version
----------------------------------------

All the way back to 386BSD's /etc/MAKEDEV script, and probably prior to
that, group operator had read-only access to disk devices:

    fd*|wd*)
            umask 2 ; unit=`expr $i : '..\(.*\)'`
            case $i in
            fd*) name=fd; blk=2; chr=9;;
            wd*) name=wd; blk=0; chr=3;;
            esac
            case $unit in
            0|1)
                    mknod ${name}${unit}a   b $blk `expr $unit '*' 8 + 0`
                    […]
                    chgrp operator ${name}${unit}[a-h] r${name}${unit}[a-h]
                    chmod 640 ${name}${unit}[a-h] r${name}${unit}[a-h]

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.

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.

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.

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

The third half of the mess is that there is no definition of what
group=operator is even supposed to mean:

    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

There are 74 kernel source lines contain GID_OPERATOR plus,
obviously a 75th line with the #define.

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

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

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 ?

That way lies GID_BIKESHED.

We also have devfs(8) and devd(8) now.

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

Hint: Not even freefall.

Maybe GID_OPERATORs days have come and gone, so we should ?

	s/GID_OPERATOR/GID_WHEEL/

Poul-Henning

(Who makes absolutely no apologies for the Subject line.)

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