3 ms·

Tangential-ish question: It's often claimed that the Linux /proc virtual filesystem has roots in Plan 9's design, and it's certainly a very powerful abstractio

Tangential-ish question: It's often claimed that the Linux /proc virtual filesystem has roots in Plan 9's design, and it's certainly a very powerful abstraction that allows, at the cost of some expressiveness, near-universal interoperability with some of Linux's internal state. However, many BSDs do not support it out of the box, and I've heard it claimed that they're deprecating/have no plans to keep /proc around, favoring sysctls which return structs instead. Assuming that both are true (/proc came from plan9 and BSDs are moving away from it), why is this the case? Why abandon a universally-interoperable, so-simple-a-child-can-interface-with-it interface to what is otherwise a very hard-to-work-with type of system state?

stonogo 9y ago
Because abandoning a universally-interoperable, so-simple-a-child-can-interface-with-it interface to what is otherwise a very hard-to-work-with type of system state is easier than fixing file descriptor exhaustion problems.
mveety 9y ago
I think some of the reason the BSDs are moving away from it is no one uses it much and no one really maintains it. It just never got the traction on BSD like it did Linux. procfs should just be the place to get information on and fiddle with processes, but on Linux, for example, you can fiddle with all manner of unrelated extraneous things. This caused the different procfs implementations to all be different enough to kill interoperability making it so that POSIX was the only fallback. So, if you wanted to write a cross-platform process fiddler you would need to use POSIX or write a number of different codepaths to interface with the number of different procfses. This lack of interoperability and replication of features was probably what killed it. Going to expressiveness: procfs is more expressive than using structs or so. It does all of what the structs do, but are more available to programs than the structs because its all some files. On 9front you're able to mount another machines procs and debug or whatever the programs running on that machine. Also you're able to use any language you want if it can read files because you don't need to use any external functions beyond the syscalls.
jcranmer 9y ago
Exposing kernel bits via the filesystem makes less sense the more you think about it: * You have to build a state machine inside the kernel to handle cases like applications reading a file one byte at a time. * If the API is complex, you get to build parsers (aka, the easiest way to introduce buffer overflows in C) in kernel-mode. * Programs now have to deal with malicious applications capable of managing mountpoints giving fake results via the filesystem. I could link to /dev/random to /dev/zero, how many programs are going to check for that? * You can't let the program go into a chroot jail if it needs to read the kernel's magic filesystem. * You have to mingle filesystem access bits with kernel security checks for process capabilities and the like. It's definitely not a simple interface for the kernel to implement, and, quite frankly, it's much more complex for a security-minded application to poke at the kernel through a filesystem than it is through a syscall.
- anjbe 9y ago
  Another entry for your list: vulnerability to file descriptor exhaustion attacks. This (and the chroot issue) is why OpenBSD promotes their arc4random() interface for generating random numbers rather than /dev/random.
- zbentley 9y ago
  That's a useful list, thanks. It's also saddening: almost all of those items are in the "it's hard to implement" category. I get that free software development is hard and self-directed, but it still bums me out that people are willing to toss the baby out with the bathwater. A couple of those points seem plain wrong/misleading, though: > Programs now have to deal with malicious applications capable of managing mountpoints giving fake results via the filesystem. If malicious code has privileges to change the pseudo-device paths for /dev/zero and /dev/random on your system you can easily be compromised regardless. Such code could sniff your network traffic, put junk data into any file (or socket descriptor, since it could probably also install a tap) your program used, and likely also debug/inspect/halt/alter the runtime behavior of the victim process(es). > You can't let the program go into a chroot jail if it needs to read the kernel's magic filesystem. This is technically true, but I think it would be possible to develop a convention or standard for chrooted programs that resulted in certain "capabilities" (e.g. "can it use procfs? which parts? how about /dev/zero?") being present in standard locations inside the jail. It is more implementation/standardization work, though, so this isn't a criticism--more of a regret.

stonogo 9y ago

Because abandoning a universally-interoperable, so-simple-a-child-can-interface-with-it interface to what is otherwise a very hard-to-work-with type of system state is easier than fixing file descriptor exhaustion problems.

mveety 9y ago

I think some of the reason the BSDs are moving away from it is no one uses it much and no one really maintains it. It just never got the traction on BSD like it did Linux. procfs should just be the place to get information on and fiddle with processes, but on Linux, for example, you can fiddle with all manner of unrelated extraneous things. This caused the different procfs implementations to all be different enough to kill interoperability making it so that POSIX was the only fallback. So, if you wanted to write a cross-platform process fiddler you would need to use POSIX or write a number of different codepaths to interface with the number of different procfses. This lack of interoperability and replication of features was probably what killed it. Going to expressiveness: procfs is more expressive than using structs or so. It does all of what the structs do, but are more available to programs than the structs because its all some files. On 9front you're able to mount another machines procs and debug or whatever the programs running on that machine. Also you're able to use any language you want if it can read files because you don't need to use any external functions beyond the syscalls.

jcranmer 9y ago

Exposing kernel bits via the filesystem makes less sense the more you think about it: * You have to build a state machine inside the kernel to handle cases like applications reading a file one byte at a time. * If the API is complex, you get to build parsers (aka, the easiest way to introduce buffer overflows in C) in kernel-mode. * Programs now have to deal with malicious applications capable of managing mountpoints giving fake results via the filesystem. I could link to /dev/random to /dev/zero, how many programs are going to check for that? * You can't let the program go into a chroot jail if it needs to read the kernel's magic filesystem. * You have to mingle filesystem access bits with kernel security checks for process capabilities and the like. It's definitely not a simple interface for the kernel to implement, and, quite frankly, it's much more complex for a security-minded application to poke at the kernel through a filesystem than it is through a syscall.

anjbe 9y ago
Another entry for your list: vulnerability to file descriptor exhaustion attacks. This (and the chroot issue) is why OpenBSD promotes their arc4random() interface for generating random numbers rather than /dev/random.
zbentley 9y ago
That's a useful list, thanks. It's also saddening: almost all of those items are in the "it's hard to implement" category. I get that free software development is hard and self-directed, but it still bums me out that people are willing to toss the baby out with the bathwater. A couple of those points seem plain wrong/misleading, though: > Programs now have to deal with malicious applications capable of managing mountpoints giving fake results via the filesystem. If malicious code has privileges to change the pseudo-device paths for /dev/zero and /dev/random on your system you can easily be compromised regardless. Such code could sniff your network traffic, put junk data into any file (or socket descriptor, since it could probably also install a tap) your program used, and likely also debug/inspect/halt/alter the runtime behavior of the victim process(es). > You can't let the program go into a chroot jail if it needs to read the kernel's magic filesystem. This is technically true, but I think it would be possible to develop a convention or standard for chrooted programs that resulted in certain "capabilities" (e.g. "can it use procfs? which parts? how about /dev/zero?") being present in standard locations inside the jail. It is more implementation/standardization work, though, so this isn't a criticism--more of a regret.