From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Thu, 21 Aug 2008 17:39:59 +0100 From: Eris Discordia To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Message-ID: <87FC045629EC20370EB3CD77@F74D39FA044AA309EAEA14B9> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Subject: Re: [9fans] Using the Acme Editor Topicbox-Message-UUID: 04a4efe4-ead4-11e9-9d60-3106f5b1d025 > Virtualization and jailing are hacks to work around the inherent Virtualization is much more than that. It has a future and the future's=20 here. It also has a rather glorious past in IBM VM/CMS. > restriction ('only root can become another user', hence su/sudo, only > root can open certain ports, etc.) which Plan 9 cleanly does away > with. By assuming _anyone_ at a terminal is root, while sometimes the "terminal"=20 is not a terminal at all. What happens when your home computer is=20 bootstrapped? Is there a thing glenda can't do? I mean, if someone other=20 than you turns your home computer on is it OK for them to be entitled to=20 the same privileges that you normally are? Assuming there's method of=20 stopping them from disconnecting the hard disk inside and/or from peeking=20 into the data on it (there are practical solutions for both of these=20 problems). > A plan9 terminal can run programs, and can have a local storage file > system, with multiple users. As for authentication, in such use case > unix auth is little more than a farce of security theater which could > easily be implemented in plan9 (and I think some people has) if you > wanted to keep your three year old child from accessing your account > but is futile for much else. A "terminal" per se should be dumb. How come it can run programs? It seems=20 a Plan 9 term isn't exactly a terminal, not a dumb one for sure. If it can=20 run a program, any program, who's going to control what the program=20 accesses, especially when there are _multiple_ users some of whom may not=20 be exactly trustable and there's a local store of sensitive information? Basically, a terminal should not hold _any_ information on its users. Where = does the security of not keeping authentication information on a so-called=20 terminal go when you _keep_ it on the "terminal?" But with multiple users=20 you're going to need authentication. Right? My impression: the UNIX authentication "farce" happened because UNIX began=20 as a replacement to a time-sharing system for more or less physically=20 secure computers but then was downsized to an OS--many OS's, in fact--also=20 usable on personal computers, e.g. 386BSD. Personal computers aren't as=20 physically secure as the proverbial "big computer in the basement," hence=20 the need for role-based security which was, incidentally, introduced in=20 386BSD. However, as long as the physical security problem persists the=20 "farce" goes on. Nothing wrong with UNIX. The twist is in the placement and = role of personal computers which can be flaky vessels for sensitive=20 information. Plan 9 doesn't solve that problem for the most common form of computer,=20 i.e. the _home_ computer. Not even for the so-called "workstation." It=20 solves the problem only for the corporate/university/organization "access=20 point," if you know what I mean. Even then that isn't a _new_ solution--it=20 was there when the original time-sharing systems were in operation. Of=20 course, the Plan 9 solution costs--any solution does--and for the home=20 computer these costs aren't followed by gains. The real problem: "standalone" terminal, also known as the home computer The real solution: physical security for anything that may carry sensitive=20 information. Physical security must include software security against=20 physical threats as well, e.g. encryption. As a side note, Rob Pike has been quoted--I take no responsibility for=20 authenticity--saying, "a smart terminal is not a smart ass terminal, but=20 rather a terminal you can educate." That's the root of the problem: underestimation of home computers. A home=20 computer is a smart terminal as well as a smart ass terminal and there's=20 nothing you can do about it. > Try to do ioctl over the network. I think I said ioctl serves a less generic function. > Here is a reason: Because Plan 9 has no network-related syscalls, and > applications contain no networking code (even when they are still > network transparent thanks to 9P), when ipv6 was added to plan9, no > [...] UNIX can accommodate this approach any minute now, figuratively speaking.=20 It has the infrastructure. Current networking traditions in UNIX aren't=20 inherent, they're circumstantial. Remember, the file system abstraction=20 began in UNIX--or even before UNIX? > I don't think any unix systems allows a single application (or > namespace) to access *multiple* network stacks concurrently... and > remote network stacks? don't think so either. So, what exactly is happening when the same process is sending HTTP=20 requests to a server on the local 802.3 network, a second server on the=20 Internet accessible through my dial-up connection, and a third server on a=20 802.11 network? Aren't there _three_ network stacks beneath (or over? the=20 PPP, the Ethernet, the WiFi interfaces? To my meager knowledge, these are=20 distinct at least up to network layer, i.e. physical-to-host, medium access = (if present), and data link layers are different. > namespace) to access *multiple* network stacks concurrently... and > remote network stacks? don't think so either. Accessing another computer's network stack is possible through RPC. Though=20 the actual requirements for that feat are way beyond my scope. > Ah, interesting example, isn't it sad that every database system on > unix (or windows) needs to include its own networking code, its own > authentication, etc.? Please take a look at a simple application using System::Data::DataGrid.=20 Networking is completely transparent to the DataGrid class. It's been=20 abstracted like in Plan 9, though not in a technically identical way. In=20 fact, .NET framework has a whole range of abstractions for various = purposes. --On Thursday, August 21, 2008 9:42 AM +0200 Uriel =20 wrote: > On Wed, Aug 20, 2008 at 11:46 PM, Eris Discordia > wrote: >> Thank you, sqweek. The second golden Golden Apple with = =CE=BA=CE=B1=CE=BB=CE=BB=CE=B9=CF=83=CF=84=CE=B9 >> on it is totally yours. The first one went to Russ Cox. >> >>> You don't care who mounts what where, because the rest of the system >>> doesn't notice the namespace change. >> >> So essentially there shouldn't be a problem with mounting on a single >> "public" namespace as long as there is one user on the system. mount >> restriction in UNIX systems was put in place because multiple users = exist >> some of whom may be malicious. Virtualization and jailing will relax = that >> requirement. > > Mount restrictions on unix are needed (among other reasons) because of > a broken security model (ie., suid). > > Virtualization and jailing are hacks to work around the inherent > limitation that in unix resources can not be easily > abstracted/isolated and are plagued by the 'only root can do X' > restriction ('only root can become another user', hence su/sudo, only > root can open certain ports, etc.) which Plan 9 cleanly does away > with. > > Linux could do many things plan9 can do, if it got rid of all suid > programs (by perhaps using the cap device implementation for the linux > kernel, if that is ever accepted in mainline linux), but until then... > >>> Uh, what now? You either have an interesting definition of home >>> computer or some fucked up ideas about plan 9. You only need a cpu >>> server if you want to let other machines run processes on your >>> machine. You only need an auth server if you want to serve resources >>> to a remote machine. >> >> Neither statement is true. On a home computer you certainly need a term. >> You'll need a cpu for a number of tasks. And you'll need auth if there's >> going to be more than one user on the system, or if you need a safe way >> of authenticating yourself to your computer. A single glenda account >> doesn't quite cut it. If you're going to access your storage you'll need >> some fs('s), too. >> >> The bottom line is: term is _certainly_ not enough for doing all the >> tasks a *BSD does, and requiring a home computer to do all these tasks >> is far from inconceivable. One *BSD system is almost functionally >> equivalent to a combination of term, cpu, auth, and some fs('s). > > A plan9 terminal can run programs, and can have a local storage file > system, with multiple users. As for authentication, in such use case > unix auth is little more than a farce of security theater which could > easily be implemented in plan9 (and I think some people has) if you > wanted to keep your three year old child from accessing your account > but is futile for much else. > >>> incantation, that's beside the point. In 9p, the abstraction is a file >>> tree, and the interface is >> >> auth/attach/open/read/write/clunk/walk/remove/stat. >> >> ioctl and VFS are suspiciously similar even though they serve less >> generic functions. > > Try to do ioctl over the network. > >>> network operations - everything is done via /net. Thanks to private >>> namespaces, you can transparently replace /net with some other crazy >>> [compatible] filesystem, which might load balance over multiple >> >> How does that differ from presenting of a network interface by a block >> device on UNIX? And why should avoiding system calls be considered an >> advantage? Your VFS layer could do anything expected from /net provided >> that file system abstraction for the resources represented under /net is >> viable in the first place. > > Here is a reason: Because Plan 9 has no network-related syscalls, and > applications contain no networking code (even when they are still > network transparent thanks to 9P), when ipv6 was added to plan9, no > changes were required to either any syscalls or any applications. On > the other hand on unix they are still to this day adding ipv6 support > to certain apps (and every app that needs to access remote resources > needs its own networking code that is aware of each protocol it wants > to support, etc). > > When ipv6 needs to be replaced, the pain in the unix software > ecosystem will be even greater, while in plan9 it will be virtually > painless. > > There are also the benefits of allowing different applications > (namespaces) use different network stacks without requiring full > virtualization of the whole OS (the few unix systems that have been > able to implement this functionality have done so after many years of > painful efforts and the result is incredibly clunky and complex), and > I don't think any unix systems allows a single application (or > namespace) to access *multiple* network stacks concurrently... and > remote network stacks? don't think so either. > >> >>> implemented on any system, which is true [to an extent]. But it's >>> apparent than no others have the taste to do it as elegantly as plan 9 = - >> >> It's not a matter of taste. There are situations, many situations >> actually, where the file system abstraction is plainly naive. Sticking >> with it for every application verges on being an "ideology." >> >> The VFS approach is by no means inferior to Plan 9's >> everything-is-a-file, but on UNIX systems it is limited to resources >> that can be meaningfully represented as file systems. Representing a >> relational database as a file system is meaningless. The better >> representation is something along the lines of the >> System::Data::DataGrid class on Microsoft .NET framework. > > Ah, interesting example, isn't it sad that every database system on > unix (or windows) needs to include its own networking code, its own > authentication, etc.? > > Peace > > uriel