The /proc filesystem is pretty nifty, but I always kinda feel weird about using it for system introspection.
Any thoughts from the ‘nix or BSD devs that lurk here?
OpenBSD has gone all in on the sysctl() interface instead. I can think of three advantages.
Not in the filesystem namespace. Everything is a file is awesome, until people find ways to trick their sftp only restricted shell into opening its own /proc/mem and rewriting itself. A number of security models depend on files over here and processes (instruction streams) over there and sticking everything in the same basket leads to hijinks.
Atomic snapshots. A single sysctl() call should return a mostly coherent snapshot of all running processes. Running ps and scanning over /proc leads to race conditions where you might see two processes in the same listing, even though one exited before the other started.
The interface uses fixed structs, which are easier to parse than strings.
The disadvantages are basically the flipside. Maybe you really do want to reimplement ps with a bunch of sh and sed, and reading strings out of files is just dandy…
mostly coherent snapshot
aw cmon tedu don’t leave us hanging like that. Elaborate?
I didn’t want to overstate the promise, but there’s nothing I’m aware of. At least on OpenBSD, while sysctl() is running in the kernel, no other process can fork or exit. The exception is reading the full argv list for a process, which requires a second call per process, thus you might see a ps listing with an impossible combination of arguments (since a process can change it’s own argv).
So, theoretically, I could DoS an OpenBSD box by causing a lot of sysctl() traffic and prevent creation of new shells or forked handlers or whatever?
Sure, but if that’s your purpose, while (fork()) _exit(0); will create even more load, and less visibly too.
while (fork()) _exit(0);
The proc(4) file system on illumos is mostly unlike the one on Linux. There’s some history in a paper by Roger Faulkner, though the modern version described in the manual page is at least one generation removed from that. The old interface was ioctl(2)-driven, but the newer one involves reading and writing message objects (documented and available as C structs) to particular control files.
In our universe, the control interface exposed through /proc serves many purposes, including:
In addition to the files themselves, we also provide a rich C library of accessor and utility routines upon which to build additional tools – obviating the need to directly manipulate the files in many cases. This library is capable of performing many of the exact same functions against core files as well (via Pfgrab_core(3PROC)), allowing debugging and observability tools to work both live and post-mortem with relative ease.
Security restrictions are provided in a number of ways, primarily centred around our privileges(5) subsystem. The proc_info privilege is required in order for processes other than your own to be visible in /proc, and the traditional root-reserved behaviour of cross-account process manipulation is granted (or denied) via the proc_owner privilege. Several other fine-grained proc_* privileges also exist. Tighter sandboxing of child processes (e.g. ftpd or scp processes), or indeed of entire user accounts, can be arranged via use of the privileges framework.
It’s theoretically the most Unixy way to do things. Linux’s procfs is actually a concept taken from Plan 9, which put everything as a file - and that included processes.
I like the idea of procfs but IMHO the Linux implementation is another example of all that’s wrong with the Bazaar development model. Developers add whatever they want and without a set of guidelines it’s ended up a mess. Just read the manpage for a taster…
Yep! The Plan9 stuff was so cool, even if the security model looked like alien space magic.
I dislike procfs with a passion. Back in 2014, someone figured out how to abuse procfs to force sftpd to drop into a shell. If I remember right, OpenBSD fully removed procfs. HardenedBSD has hardened both procfs and linprocfs. It’s a really interesting attack vector from a security perspective.