Security in Plan 9 (2002) | Hacker News Reader

Security in Plan 9 (2002)

9p.io

146 pointsjsfcoding66 comments

Interesting related topic - Inferno OS security, discussed in this Phrack magazine article: http://phrack.org/issues/58/12.html

The 9p filesystem lives on in a few "modern" places, like within WSL, QEMU, and other places where it's a good bridge between a host OS and container or VM.

Apple added support just in 2019!

  man mount_9p

Huh, could one use this instead of NFS then?

If you don't like performance very much - sure :-).

Anyone have an example, say of how to use this command to mount the public plan9 repo?

I've not messed with it, but will once I find some free time.

There is an old KEXT on GitHub [0] that can mount them from the Finder, but KEXTs are on the way out...

[0]: https://github.com/benavento/mac9p

I'm fairly sure that it's used on Mac for the virtualization frameworks when working with guest VMs.

unless i have done it hopelessly wrong, you may be overstating it a little bit by calling it good.

virtfs is the good one, not 9p.

virtfs USES 9p.

I think GP meant to say (the extremely confusingly named) virtio-fs, as opposed to virtfs/9pvirtio.

Virtio-fs is independent of 9P and has optional support for using shared memory to greatly increase performance, it also maps better to the permissions and metadata of "modern" filesystems IIRC, not sure if 9pvirtio had this problem but I remember coworkers having permissions problems with the 9P bridge in WSL2 (Plan9's permission system is very simple and doesn't map well to other VFS's)

> Plan9's permission system is very simple and doesn't map well to other VFS's

Plan 9 is a pure VFS OS. 9p uses regular unix permissions which map just fine. The major issue is that since plan 9 is all vfs, there are no crufty unix leftovers like hidden dot files or hard/soft links. User specific configuration files belong in $user/lib and bind replaces hacky links. These old unix hacks were accommodated in 9p2000.u. Further extensions to .u resulted in 9p2000.L which adds some Linux metadata stuff (I cant remember right now, my memory of 9p2000.u/L is fading).

Unfortunately it's not implemented for Windows hosts. There's a patch in the works but the review of the first submission came back with a lot of requested changes. They're planning another submission though so hopefully it makes it in.

ChromeOS uses it as well to proxy files between containers.

Plan 9 seems to be disproportionately influential for an OS nobody who's not into systems engineering has ever heard about.

to be fair, it's where UTF-8 debuted

and /proc

Unfortunately, kids these days seem to be afraid of files. For a hardcore unix fan, curl and wget are useless tools when you can just cat /www/url

It's seems nice on a first glance. But how do you set headers and content type for example?

You echo the request into /www/url and cat the response from it

or even better, to avoid state, the url "file" is executable and you pipe through it:

    /www/url < request > answer

that already exists, the command is "wget -i - -o -"

How does it know where to send it? Does it just assume it should use the contents of the Host header and send the request there or is the "url" in your path the destination? Does it support things like SNI?[1] Can you spoof that? Does it expect clients to parse out the raw output of the HTTP response? I have so many questions. From a quick glance this seems a lot harder to work with than curl for both trivial and non-trivial uses.

I tried to find docs on it, but couldn't. If you could link me to some, I'd appreciate it.

[1] After posting this I remember like a doofus this is an OS from the 90s. Of course it doesn't. But a similar question could be asked about any other TLS level setting. That's just one I've had to spend more time debugging using curl in the past.

To be fair you'd probably end up with a tool like curl just for setting all the options and headers, but it would just be a wrapper around sending the request to the url file. Just like there are tools for reading and parsing files in /proc.

/proc predates plan9, plan9 just made it hierarchical

https://en.wikipedia.org/wiki/Procfs#History

> kids these days seem to be afraid of files

Sad but true. Android and iOS are the worst offenders I've seen. They're apparently trying to completely get rid of the concept of files altogether, which is really unfortunate for anyone wanting to build cool stuff on those platforms.

I understand there can be security benefits but at what cost.

> They're apparently trying to completely get rid of the concept of files altogether

I’ve never followed Android very closely but iOS began with no user-facing notion of files and added one many years and major releases later. Granted they’re not Unix everything-is-a-file, as in you can’t execute them or do all sorts of other everything-is-a-file operations with them. But adding mostly-general file functionality is definitely not trying to get rid of the concept.

/proc is cute for manual tasks but utterly broke as an API due to inherent races and issues passing context around.

So utterly broke that the poor "htop" program cannot work at all... oh wait

     $ strace htop 2>/tmp/e   # wait for htop to load and then press 'q'
     $ cat /tmp/e | grep ^open | grep /proc | wc -l
     49817

htop is essentially "find /proc" with a pretty output. Is htop broken for you?

There’s no need to be snarky, especially when you’re missing the point. htop missing a race on a PID is no big deal. GDB doing so is a critical issue. /proc is nice to have for diagnostics but once again it makes for terrible API.

And yet Plan 9 has a curl/wget equivalent, `hget`.

In the ideal world this would be a two-line wrapper that just calls cat on the given url

UTF-8 worth prize.

It's mostly coz some people that worked on it went to big companies. Go being one example.

I think you're looking at the wrong end of the timeline. The people who built it had already built UNIX and C (and one of them would later write Limbo). Go's initial splash in the "press" was helped massively by that pedigree.

I do have distinct memories of Go's initial hype being « Ken Thompson and Rob Pike did this ».

I meant that if same people went to work to some small unknown company nobody would care as none of their software would have a pull of something pushed by Google

I know that's what you meant and you absolutely have it backwards. These are the people who built some of the most iconic technology BEFORE building Plan 9. Are you seriously not familiar with their work on UNIX and C at Bell Labs? Because all of them were legends long before going to Google. Them going to Google was a big deal because of who they already were, not Google. If you're not old enough to remember their ideas being a big deal before they joined Google you need to go do some reading because you're lacking pretty real historical context.

It's a similar story with the Self programming language (https://en.wikipedia.org/wiki/Self_(programming_language). There are many software engineers and computer scientists who never heard of Self, but Self's prototype-based approach to object-oriented programming had a major influence on JavaScript, and a lot of the work done on making fast virtual machines for Self made it in the Java Virtual Machine.

When it was first announced, it wasn't clear it would end up being so esoteric, but I remember that Ken Thompson, Dennis Ritchie, and Rob Pike were working on it, and maybe Brian Kernighan too?

Timing-wise, it was too late for what they ended up doing, but anything all those people worked on is bound to have some interesting ideas.

It's been weird watching the rise of iOS loosen the reliance on, or even awareness of, files, when 9P was all about files. Files for everything!

Was timing the issue though? Wasn't it released during that period of confusion of the Unix wars before GNU/Linux took over the world?

I had the impression that it was held back by its proprietary license.

> I had the impression that it was held back by its proprietary license.

That was my impression, too. And then it got relicensed to a FOSS license... that was GPL-incompatible. And then it got relicensed again to GPLv2, and then it got relicensed yet again to its current MIT license.

In any case, each of these license changes was too little too late to really improve Plan 9's practicality from a "can I legally use this?" standpoint.

I tried to install it once, a long time ago (around 2000?). Linux was already taking off, BSD's had the possibility to overtake it, other unices were made available more for the end user.

But basically, the hardware support was pretty bad. It took me a long time to find a SCSI controller which was supported, when ATA disks were already standard for years. Same with network- oder graphic cards.

Nowadays, if esoteric OS's would just support standard Vmware hardware, they'd be much more successful (looking at you fuchsia!)

Super interesting read. Some really good ideas come out of p9, but very few of them actually made it into tools we use in mass.

For those interested, Himitsu[1] is based on the design of Factotum, but ported to *nix. It's actually a pretty good systems secret store.

[1]: https://drewdevault.com/2022/06/20/Himitsu.html

https://archive.ph/FemdD

https://web.archive.org/web/20220403200715/https://9p.io/sys...

The site seems to be down.

Yeah I couldn’t access it either, Wayback archive: https://web.archive.org/web/20220403200715/https://9p.io/sys...

That is the best security.

Next up in the blog schedule: "Performance and Scaling in Plan 9"

I'd actually love to see such a paper. Plan 9 threading is more like coroutines, but it is certainly possible to run multi-core/multi-process code.

That said, I can't say I've seen anyone try to write anything that scales like nginx on Plan 9. That doesn't mean it hasn't happened, I've just not seen anyone talk about it too much.

It did run on IBM's Blue Gene for a bit (https://www.usenix.org/legacy/event/usenix07/posters/vanhens...) but as you can see that was some 15 years ago, and I'm not sure we're talking about anything even remotely similar to a single computer handling tons of concurrent connections.

Plan 9 can also run Go binaries, but, again, not really sure we're talking about the same thing as nginx-level scale.

> I'd actually love to see such a paper. Plan 9 threading is more like coroutines, but it is certainly possible to run multi-core/multi-process code.

Rob Pike was on of the main developers behind plan 9 and Go and involved in concurrent programming research focusing on CSP.

Multi-processing was a main focus of plan 9's design and it works well as procs are cheap to spawn on plan 9. Procs are also the smallest unit of execution on plan 9, threads are just light weight procs with a shared heap to pass pointers around. Thread stacks can also be shared as well by being allocated on the heap via fork(2) RFMEM flag (its all done with malloc in the background).

The issue with vanilla (aka labs or legacy ) plan 9 is there is a hard coded limit of 2k procs statically allocated at boot. This was a pragmatic design decision. The unfortunate side effect is vanilla plan 9 falls over under any sort of work load requiring spawning lots of procs like handling web requests. This is actively being worked on by 9front developers so sites hosted on 9front should hold up better (patches welcome :-).

> That said, I can't say I've seen anyone try to write anything that scales like nginx on Plan 9.

Because you really don't need those big web serving monoliths on plan 9. You wire things up using rc scripts and programs like execfs (implements cgi) plus httpd/tcp80 or another web serving listener and sandbox code using namespaces. Plan 9 is more true to unix philosophy and more unix than unix. (edit: execfs is experimental but available on shuthub.us along with other webstuff like tcp80)

rfork is also just a really elegant system call

And also Limbo and Inferno, Plan 9's sucessor that people keep forgeting about and heavily influenced Go.

https://www.vitanuova.com/inferno/limbo.html

Plan9 libthread is literally goroutines just without the syntax sugar - up till version 1.5, golang shipped significant chunk of Plan9 standard library with itself. It's also where the saner networking interface came from, as Plan9 was to support networking from start, not depend on quick and dirty port of non-Unix stack like BSD Sockets

It got taken care of in Limbo and Inferno, Plan 9's sucessor that people keep forgeting about and heavily influenced Go.

https://www.vitanuova.com/inferno/limbo.html

Already done.

https://orib.dev/9hack1.html

Still WIP. We're not yet at a million useful procs.

Ah, by "Already done" I was referring to to the fact that your blog post exists and addresses the performance issues :-)

Hosted on a plan9 system

And? One can run a not-so-scalable web server on any OS last time I checked.

Ease up, I'm quite sure it was a joke.

It would have been funny for a blip but this has been front page for >6 hours and it's still down

Would love to "Lego" block build hardware and software components on the following stack:

1. RK3588 Rockchip 12in Thinkpad cross HTC style slideout keyboard form factor 2. Plan 9 Legacy OS 3. seL4 microkernel, Qi cross Racket IDE

and to compete what people can do scaling out to the "cloud" at price thresholds, maybe a gifted individual or team will realise the 2100 movie's HAL9000 sentience.

It seems to go down every time something on it is submitted to Hacker News. Give it a few hours and try again.

Here ya go

http://git.9front.org/plan9front/plan9front/e938acc8ff64a3cb...

Weird to link to the raw troff. One you install 9front or plan 9, you run mk in /sys/doc to render into readable ps/pdf/html documents.

If someone wants to use/learn Plan9/9Front:

http://9p.sdf.org/

Reply on news.ycombinator.com