From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Thu, 1 Jan 2009 18:57:16 -0500 From: Nathaniel W Filardo To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Message-ID: <20090101235716.GC8355@masters10.cs.jhu.edu> References: <1230850413.11463.79.camel@goose.sun.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0vzXIDBeUiKkjNJl" Content-Disposition: inline In-Reply-To: <1230850413.11463.79.camel@goose.sun.com> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [9fans] sendfd() on native Plan 9? Topicbox-Message-UUID: 74acb7cc-ead4-11e9-9d60-3106f5b1d025 --0vzXIDBeUiKkjNJl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 01, 2009 at 02:53:33PM -0800, Roman V. Shaposhnik wrote: > On Tue, 2008-12-30 at 10:31 -0500, erik quanstrom wrote: > > > You have to ensure that I can't dial it and authenticate with > > > factotum. It's a mess!) > >=20 > > how would that attack work? > > > > supposing that you have a fully jailed process. if it has a connection > > to the fileserver, which does do security by user id, the jailed process > > can still mess with you. say by deleting all your files. Yes, exactly. I don't understand the question? =20 > > i think the real question here is why don't you trust your > > processes? is it because someone else is running them >=20 > That was, essentially, my original question. Nathaniel, could you, > please answer it? I'm looking at a system like 9gridchan where an essentialy autonomous agent publishes services. A bug in this server which revealed all of /srv, rather than the parts of /srv it's supposed to, would be tragic. I'd be much, much happier if the bar were raised from server compromise to local kernel compromise. Further, 9gridchan pollutes the namespace of /srv for everybody else on the system, and its current naming scheme makes it impossible to run two 9gridchan agents (w/o modification) even as different users. I also want, I think, an extension to 9gridchan where I can publish a service which relays for other 9gridchan nodes, which essentially means that remote machines are directing the contents of my /srv. (I want this so that I can bounce around NATs or loss of direct connectivity in the 9gridchan mesh... other proposals for solving this problem welcome.) While fixing 9gridchan could solve some of this, the problem is more general. The global unified name space of /srv is reminiscent of the UNIX /tmp nightmare, where processes and users have to guess as to names that won't collide or iterate around create() or, in the worst case, just fail outright (e.g. somebody has posted a file name 'sources' into /srv that isn't a connection to sources). However, /srv is currently the only mechanism (AFAIK) for a fd in a pgrp A to be given to a process in pgrp B. Therefore, if /srv is to be virtualized (made a property of namespaces) ala /tmp, then something like sendfd() seems to be necessary to replace this functionality when required. Does that help answer the question? Am I totally lost in the woods? (It's always possible...). Thanks. --nwf; --0vzXIDBeUiKkjNJl Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkldWFwACgkQTeQabvr9Tc8/wgCbBPE4icDzpduz3HsLxDstGI3S MR8An3i7/HmLTnqUQt6vul0f58vEcS55 =bv0n -----END PGP SIGNATURE----- --0vzXIDBeUiKkjNJl--