From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: To: 9fans@9fans.net From: erik quanstrom Date: Sat, 3 Jan 2009 16:41:53 -0500 In-Reply-To: <1231017782.11463.193.camel@goose.sun.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] sendfd() on native Plan 9? Topicbox-Message-UUID: 76a49766-ead4-11e9-9d60-3106f5b1d025 > 1. Virtualizing root account, so that every Zone can have its own > 2. Virtualizing the global UNIX namespace > 3. Virtualizing TCP/IP stack > 4. Virtualizing drivers providing access to the service provided > by the kernel itself (things like /proc, etc.) > 5. Implementing per-Zone quotas on CPU, Memory and I/O consumption > > Now, under Plan9, #1-3 come for free. I'm not sure how #5 is possible > (anybody?). And thus #4 is the only are that needs work. That work, there isn't a root account, but there is still only one eve. also, there can only be one ip stack per physical interface. (this could be fixed by changing two or three lines of code.) there's also nothing preventing one from implementing a filtering fs that restricts the directories available in /proc. i'm not quite sure what the point is. if the problem really is security, then i would the security problems should be fixed. > a channel (either existing or a new one). From the point it connects > *and* passes the auth process, you are constrained by the security > model of 9P. Users and user groups are the only thing that is there. note that in plan 9, groups only exist on the file server. the auth server doesn't know anything about them - erik