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

51–60 of 75 posts

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

#51

Post by DarylZero »

stormbrew wrote: post #30
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.

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 co…

The thing about `sudo` is confusing because you don't even need to modify the namespace to overwrite `/etc/sudoers` if you have root. You just need to write to the file.

What it sounds like plan9 is doing is giving a local view of the root that local processes see. Which Linux can do too. Not with the same use-cases in mind as Plan9 though, as such capabilities were added for sandboxing/containerization. But the mechanisms are probably(?) general enough to do Plan9 in Linux.

A `sudo` that is seeing a local view of the root is going to have privileged access to that local root, not to the global system root. And that is correct. That is what sudo does. It gives root access to the same root that contains /etc, not to any "outer" or "more global" root.

It doesn't mean you can't have any access to the global root from the local root though. There are many ways to arrange such privilege escalation. (They do have to be arranged, of course, by someone writing the userspace code -- like sudo had to be written.)

>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.

Privileged processes can have a global view of the namespace while the user does not. An ordinary setuid binary on a filesystem the user controls can't get a global view, only because the user does not (should not) have authority to do that. A process with the global view and root can grant the authority though.

The important thing, it seems to me, is that the global outer namespace can grant to the process local namespace any capabilities available through the outer namespace. I'm not sure if this is 100% completed but the ongoing containerization efforts do involve reaching toward that 100% mark.

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

#52

Post by DarylZero »

stormbrew wrote: post #32
sillysaurusx wrote: post #27

Earlier quoted context omitted.

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 ea…

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…

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.

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

#53

Post by DarylZero »

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 think you're right that I don't understand the problem.

If you want to give actual real global root, I think you can do it by having a gifting process put the real global root process into the same process namespace as the giftee process.

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

#54

Post by ori_b »

sillysaurusx wrote: post #27
ori_b wrote: post #23

Earlier quoted context omitted.

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 ea…

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.

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

#55

Post by ori_b »

DarylZero wrote: post #53
ori_b wrote: post #23

Earlier quoted context omitted.

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

I think you're right that I don't understand the problem. If you want to give actual real global root, I think you can do it by having a gifting process put the real global root process into the same process namespace as the giftee process.

And how does that interact with binding files as non-root, including /etc/sudoers.conf?

(plan 9 has no suid, so this is not a problem there)

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

#56

Post by DarylZero »

ori_b wrote: post #55
DarylZero wrote: post #53

Earlier quoted context omitted.

I think you're right that I don't understand the problem. If you want to give actual real global root, I think you can do it by having a gifting process put the real global root process into the same process namespace as the giftee process.

And how does that interact with binding files as non-root, including /etc/sudoers.conf? (plan 9 has no suid, so this is not a problem there)

I said more about that in the thread already.

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

#57

Post by ori_b »

DarylZero wrote: post #51
stormbrew wrote: post #30

Earlier quoted context omitted.

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 co…

The thing about `sudo` is confusing because you don't even need to modify the namespace to overwrite `/etc/sudoers` if you have root. You just need to write to the file. What it sounds like plan9 is doing is giving a local view of the root that local processes see. Which Linux can do too. Not with the same use-cases in mind as Plan9 though, as such capabilities were added for sandboxing/containerization. But the mech…

> The thing about `sudo` is confusing because you don't even need to modify the namespace to overwrite `/etc/sudoers` if you have root. You just need to write to the file.

The point is that you DONT have root, and you DONT have access to write to the file. But you're free to rearrange your namespace WITHOUT having root, and you want to arrange for SOME users to escalate privileges and, say, debug the kernel. Or do something else dangerous that requires elevated privileges in the global context.

> A `sudo` that is seeing a local view of the root is going to have privileged access to that local root, not to the global system root. And that is correct. That is what sudo does. It gives root access to the same root that contains /etc, not to any "outer" or "more global" root.

Yes, and that's a concise description of the flaw: you can't use suid+file based privilege escalation to modify system-wide configuration, without restricting the ability to manage freely your namespace.

This is what unix does by design, and why the authentication design from unix isn't going to work for systems used in the style of plan 9.

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

#58

Post by mixmastamyk »

IshKebab wrote: post #42
mixmastamyk wrote: post #36

Earlier quoted context omitted.

What mess?

Read the page, but essentially `/foo/bar/..` is not the same as `/foo`. It makes loads of things way more complicated than you'd expect, e.g. normalising paths now requires filesystem access, and normalising paths that only partially exist is really complicated. Another annoying issue is symlink loops, but I'm not sure if Plan 9's solution solves that.

It never caused me any real world problems, and I like making links. However am up for better solutions.

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

#59

Post by stormbrew »

throwawaylinux wrote: post #47
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…

Plan 9 fell to second system syndrome. This will hurt Plan 9 enthusiasts and probably get me flamed but it's my opinion. Not necessarily bloated or inelegant, but over engineered and over confident and missing reasons the first system was successful. Purifying and perfecting some of the concepts from unix is nice, but someone running a file server or CAD program or editing source code or compiling code or running she…

Oh I don't disagree with this at all. The main reason I wouldn't ever actually use plan9 day to day on a desktop, which is to some extent the primary use it was designed for (well, thin clients workstations really), is that the whole windowing system is just too alien.

I think most of the missteps in plan9 are above the "everything is a file" layer though. And while sockets aren't that bad, I do think I would still rather interact with them in the plan9 way than the unix way if I could.

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

#60

Post by stormbrew »

DarylZero wrote: post #52
stormbrew wrote: post #32

Earlier quoted context omitted.

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…

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.

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).

Post reply on HN