[sillysaurusx]

I feel like plan9 nerds (of which I’m one) are missing the point. People are asking “what’s so special about plan9?” and the best response is some esoteric point about a thing people empirically don’t want to do? Who cares?

There has to be a better answer than “Wow, I can make my computer that can’t run anything people want to run secure in a hypothetical hierarchical organization structure of permissions that can each have their own subtree sudo. I even call it treedo, ha-ha!” .. it just doesn’t resonate.

[stormbrew]

I dunno I think the positives are all actually pretty practical. Probably even more so today where heterogeneous computing is so much more common than it was in the 90s.

I would frequently love to have the ability to just mount a bunch of cpus off a beefier machine onto my laptop and take advantage of that to speed up my builds. I can use DISTCC but holy hell is it a lot more complicated to set up.

Or like, mounting a zip file as a directory, without needing a whole enormous systemd or gnome hairball along with fuse or gfs to make it happen as a regular user. Or hell, mount a usb stick even!

These are literally things I wish were easier every day as a software developer. The vaguely plan9-shaped bits that have been added to linux over the years have brought me no closer to them.

[DarylZero]

Fuse is how it works on Linux. Fuse is the mechanism the kernel provides to do this. So the proviso "without needing ... fuse ... to make it happen as a regular user" is terminal.

[stormbrew]

You can't mount even a fuse filesystem without root privileges (or an equivalent narrow capability). Mount is a privileged operation in linux, and it has to be for the reasons I've outlined.

In plan9 mount is not a privileged operation. Anyone can do it at any time for any reason. It does not impact or interact with the security of the system (except that you can implicitly remove access to things by unmounting them).

[NavinF]

Ahh finally a real use case in this thread.

Last time I ran into the “edit an ext4 image as an unprivileged user” problem I used a small VM.

There are people trying to fix this problem and there’s a legitimate reason why it’s hard: https://lwn.net/Articles/755593/

IIRC the patches needed for what’s described in that article are already there on Ubuntu.

[stormbrew]

I mean, yes? People are 'trying', and they're building an ever higher house of cards on which to rest this functionality. Obviously on a turing complete machine anything is possible given enough LoC, but as we've seen recently with a CVE for privilege escalation that takes advantage of one of these new 'unprivileged user can get privileges in a namespace' tricks, there's a lot of complexity and likely a lot of security issues hiding behind it.

Plan9's design makes all of this very simple, and a big part of why is the specific choice to eschew standard UNIX semantics and use a different kind of mechanism for privilege management that allowed for flexible namespaces managed outside the kernel. It also has the advantage of moving all filesystem operations out of the kernel.

So this really backs up my point, rather than contradicts it: It's only through mitigating and otherwise contradicting traditional POSIX semantics that linux is able to approach this kind of thing.

[NavinF]

> moving all filesystem operations out of the kernel

Well yeah, that’s exactly what FUSE + user namespaces does to solve this problem on Linux.

Of course normal filesystems don’t do this because it would be way too slow if the kernel can’t share data structures with the file system.

[ori_b]

The problem here is boring and practical: how do you make `bind` (or, in Linux land) `mount --bind` secure and still allow you to authenticate as a separate user, elevate permissions to change kernel config, and so on?

The authentication mechanisms on most Linuxes are based around suid binaries that read configuration files in order to decide on what to do, so if you can bind in a namespace, you can fool the authentication mechanisms.

In plan 9, this is solved with the kernel capability device. It's not particularly exciting, it's just one of the things that need to happen when you remove the concept of a global 'root user' from the system.