PAM changed everything, back in the 1990s.

* https://jdebp.uk/FGA/dont-abuse-su-for-dropping-privileges.h...

TL;DR: PAM requires session cleanup, which might require extra privileges.

> aside from a few hold-out BSDs and BSD-derived systems

One wonders if perhaps these systems weren't on to something.

It's quite possible to build and use sudo without PAM support even on Linux, most distributions just tend to build everything in "kitchen sink" mode. If I remember right on Alpine it's PAM-free by default so it doesn't need to fork. On Gentoo it's behind a USE flag.

Back in 2017, the Linux developers' notion was that not even all of this PAM stuff was enough for the parent process to be doing.

Their then asserted correct solution to TIOCSTI was that su, sudo, doas, and the like should open a pseudo-terminal and get involved in pumping pseudo-terminal I/O. They were to do this as well as, presumably, managing all of setsid(), child process stopping/suspending with a signal, and setlogname() for the new session; to keep what the old books all say about keeping the same logname even though one has switched user, and being able to use the suspend command in the second shell.

* https://www.openwall.com/lists/oss-security/2017/06/03/9

* https://www.openwall.com/lists/kernel-hardening/2017/05/10/3...

Six months ago, TIOCSTI became optional in Linux.

> Another point Alan brought up is that if a program is careless enough not to allocate a new pty, it's probably also careless enough not to close any fd's that might be open in the parent shell or by the program itself.

Oof, weird inference. File inheritance is pretty well known. TIOCSTI is really esoteric.

Requiring pam_close_session is just bad design - if it needs special cleanup, pam_open_session should grab process pidfd and spawn separate monitor process (or pass pidfd to existing daemon).

sudo is that monitor process, it's the same with how containerd and podman work, it's much much easier to babysit a process when you're its parent.

PAM predates pidfd by about 25 years or so, though it's really weird how steadfastly unix heritage systems avoided handles for important things, resulting in race conditions and security issues all over the place.

Which is definitely what you want in your authentication subsystem.

That seems like a disingenuous title, it's not abusing su, that's just one of the many things that tool was used for. That was never a bad practice, the tool just changed and pulled the rug out from under very many programs.

This article's list of privilige dropping tools is missing setpriv(1) from util-linux, which is the only one actually installed on my system.

setpriv is very much a Johnny-come-lately here, dating from 2013, which was almost a decade and a half afterwards.

If you have BusyBox installed, you have runit's chpst and setuidgid built in to it. And most Linux distributions not only package that but also package one or more of these toolsets; most often daemontools and runit, but nosh has an Arch package for example.