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!) > > > > 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? > > i think the real question here is why don't you trust your > > processes? is it because someone else is running them > > 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;
pgp50EQXkK4xF.pgp
Description: PGP signature
