Linux has lots of "do not push this" buttons, of course. We've all heard the old saw about recursively rm'ing /, but you can also recursively chmod or chown it (which breaks all the setuid bits on the system), write garbage into the /dev/sdx devices, and so on... killall5(8) and kill(-1, SIGKILL) have both existed basically forever, and this seems significantly *less* dangerous than either of them.

On the other hand, perhaps having all these attractive nuisances was never a good design in the first place. You can cry about the sysadmin "taking personal responsibility" all you want, but the way to prevent outages is to add friction in front of dangerous operations, not to castigate fallible humans when something goes wrong. But I'm not sure what that should mean for this feature in particular.

So the interesting case is a delegated cgroup. This feature is only available in cgroup v2 and in contrast to cgroup v1 cgroup v2 has a clear delegation mechanism. In order for a cgroup to be "delegated" (read "owned") by an unprivileged process the following files need to change ownership appropriately so that the unprivileged process can write to them:

cgroup.procs
cgroup.threads
cgroup.subtree_control
memory.oom.group

This is needed to correctly delegate control of a subtree to an unprivileged process. Do note that neither cgroup.freeze does nor will cgroup.kill appear in this list (cat /sys/kernel/cgroup/delegate). So even if you delegated a cgroup to a process and want it to be able to manage subtrees it doesn't mean you need to delegate cgroup.freeze or cgroup.kill too. You can leave those with unaltered ownership or even restrict it further. So even if your unprivileged process tried to freeze or kill the cgroup either on purpose or on accident it wouldn't be able to do so. But by delegating a cgroup tree you're definitely _delegating resource management_ as that's required by the implementation but imho you're also implying that delegation of _utility controllers_ such as freezer or kill is ok but you don't need to actually do it.

It was possible to get a similar effect by freezing a cgroup before enumerating pids to kill it (i.e. first stop the fork-bombs from running, then kill the frozen processes), but the freezer cgroup has its own set of gotchas--we have to wait for the freeze to take effect to be sure we've captured every pid, and that waiting means we're back to "potentially unbounded run time" and distinguishing between new processes popping up and old processes that refuse to die, and with that extra complexity we are doing only slightly better than the abomination.

If the kernel implements this capability, it can lock out new processes from being created, while it terminates old ones. Userspace can do one write(2) syscall with running time proportional to the task list size, then forget anything in the cgroup existed (unless it chooses to wait until all killed processes blocked in syscalls exit, in which case cgroup2 has an API for that). Simple, elegant, and effective.

Of course, writing something to some file named "kill" will likely wipe out some processes. No lesser result should be expected by a human writing to a file on a control filesystem with such a name. Software blindly writing numbers into new cgroup files without knowing what the numbers mean is already asking for a world of trouble--it's best to make such software notorious, so it can be removed from the world.

But...maybe it would be better if writing, say, 0x4321fedc (LINUX_REBOOT_CMD_POWER_OFF, defined in sys/reboot.h) killed the cgroup, and other values didn't? Or the string "kill" or "-9" or really anything other than the first non-zero integer.

I also wonder why it only sends SIGKILL? People often want to send SIGTERM first, and since the kill file takes a numeric value anyway, it might as well be the signal ID.

Barry