Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bell Labs' Plan 9 research project looks to tomorrow (1990)

doc.cat-v.org

Post reply on HN
Print view View original

21–30 of 75 posts

Re: Bell Labs' Plan 9 research project looks to tomorrow (1990)

#21

Post by DarylZero »

stormbrew wrote: post #5
yjftsjthsd-h wrote: post #3

Earlier quoted context omitted.

> We'll never have any of the things it really promised until we give up on POSIX, tbh. What about POSIX is in conflict with Plan 9? I would have called Plan 9 a subset of POSIX

I would call it maybe vageuly similar, but it is by no means a subset. It has some features in common and many that are completely nonsense in a posix context. The most pressing problem for implementing plan9-like semantics in a POSIX system is the permission system. In particular, setuid as a mechanism for privilege escalation. This is a big part of why users can't make their own namespaces on linux without help/int…

In modern Linux this is no problem. You can now give a process its own UID namespace. In the calling namespace its UID is non-zero, but in its own namespace it's root.

Re: Bell Labs' Plan 9 research project looks to tomorrow (1990)

#23

Post by ori_b »

DarylZero wrote: post #21
stormbrew wrote: post #5

Earlier quoted context omitted.

I would call it maybe vageuly similar, but it is by no means a subset. It has some features in common and many that are completely nonsense in a posix context. The most pressing problem for implementing plan9-like semantics in a POSIX system is the permission system. In particular, setuid as a mechanism for privilege escalation. This is a big part of why users can't make their own namespaces on linux without help/int…

In modern Linux this is no problem. You can now give a process its own UID namespace. In the calling namespace its UID is non-zero, but in its own namespace it's root.

You understood the problem backwards. How do you give out actual, real, global root, without taking away the ability to do arbitrary namespaces?

Re: Bell Labs' Plan 9 research project looks to tomorrow (1990)

#24

Post by tyingq »

stormbrew wrote: post #2

The most frustrating thing to ever happen to the concepts in plan9 is the funhouse mirror distortions of them that have landed in the linux world. They look just enough like plan9 that people think they represent those ideas, and so they have no idea how powerful those ideas can actually be and don't even know that they don't know it. We'll never have any of the things it really promised until we give up on POSIX, tb…

WSL in Windows uses the 9p filesystem protocol :)

Re: Bell Labs' Plan 9 research project looks to tomorrow (1990)

#25

Post by wbl »

MarkusWandel wrote: post #7

Unix with its "worse is better" simplicity steamrollered vastly more complex operating systems (Multics above all). It even steamrollered its own successor. Plan 9 is brilliant, but Unix already served most people's needs so why change. Mental game: If they had managed to quickly push the whole thing out as what is now called open source, while Unix was still proprietary, how would the world look now?

Plan 9 would have to contend with a huge install base issue. Remember academics had been using Unix freely since the 1960's and had a massive pile of code plus every machine worth mentioning. Plan 9 would be trying to catch up from a very delayed position.

Re: Bell Labs' Plan 9 research project looks to tomorrow (1990)

#26

Post by [deleted] »

stormbrew wrote: post #5
yjftsjthsd-h wrote: post #3

Earlier quoted context omitted.

> We'll never have any of the things it really promised until we give up on POSIX, tbh. What about POSIX is in conflict with Plan 9? I would have called Plan 9 a subset of POSIX

I would call it maybe vageuly similar, but it is by no means a subset. It has some features in common and many that are completely nonsense in a posix context. The most pressing problem for implementing plan9-like semantics in a POSIX system is the permission system. In particular, setuid as a mechanism for privilege escalation. This is a big part of why users can't make their own namespaces on linux without help/int…

[deleted]

Re: Bell Labs' Plan 9 research project looks to tomorrow (1990)

#27

Post by sillysaurusx »

ori_b wrote: post #23
DarylZero wrote: post #21

Earlier quoted context omitted.

In modern Linux this is no problem. You can now give a process its own UID namespace. In the calling namespace its UID is non-zero, but in its own namespace it's root.

You understood the problem backwards. How do you give out actual, real, global root, without taking away the ability to do arbitrary namespaces?

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.

Re: Bell Labs' Plan 9 research project looks to tomorrow (1990)

#28

Post by nmz »

MarkusWandel wrote: post #7

Unix with its "worse is better" simplicity steamrollered vastly more complex operating systems (Multics above all). It even steamrollered its own successor. Plan 9 is brilliant, but Unix already served most people's needs so why change. Mental game: If they had managed to quickly push the whole thing out as what is now called open source, while Unix was still proprietary, how would the world look now?

Unix's major feature was that it was free.

Re: Bell Labs' Plan 9 research project looks to tomorrow (1990)

#29

Post by yjftsjthsd-h »

tyingq wrote: post #24
stormbrew wrote: post #2

The most frustrating thing to ever happen to the concepts in plan9 is the funhouse mirror distortions of them that have landed in the linux world. They look just enough like plan9 that people think they represent those ideas, and so they have no idea how powerful those ideas can actually be and don't even know that they don't know it. We'll never have any of the things it really promised until we give up on POSIX, tb…

WSL in Windows uses the 9p filesystem protocol :)

As does the ChromeOS Linux VM system.

Re: Bell Labs' Plan 9 research project looks to tomorrow (1990)

#30

Post by stormbrew »

DarylZero wrote: post #21
stormbrew wrote: post #5

Earlier quoted context omitted.

I would call it maybe vageuly similar, but it is by no means a subset. It has some features in common and many that are completely nonsense in a posix context. The most pressing problem for implementing plan9-like semantics in a POSIX system is the permission system. In particular, setuid as a mechanism for privilege escalation. This is a big part of why users can't make their own namespaces on linux without help/int…

In modern Linux this is no problem. You can now give a process its own UID namespace. In the calling namespace its UID is non-zero, but in its own namespace it's root.

I dunno about the sibling comment's "backwards" comment but the thing here is that the goal isn't to prevent a user process from obtaining privileges, which is what uid namespaces are for.

This is the kind of thing I mean about "not knowing what you don't know," because you're looking at namespaces through the lens linux does, which is that they exist to limit capabilities.

Plan 9 uses namespaces to allow users to control their own environment. It's not a special operation, it's just a thing you do all the time.

For a small practical example: there's no PATH environment variable in plan9. You just union mount things into /bin, and /bin is where your shell looks for things to run. It's that much of an every day operation.

If you put a user under a uid namespace in linux, and then give them the right to create their own filesystem namespaces then sure, you've enabled them to potentially do things like this. But you've also blocked them from escalating their privileges, because now they can't use setuid binaries to obtain "real root" or whatever.

So you're left with one or the other: either you can manage your own namespace, but you have to be protected from potentially breaching root security through a setuid or cap flag on a binary; or you have to be prevented from managing your namespace outright in order to avoid lying to sudo about who can do what.

Post reply on HN