In message <20050902031915.GA15795@jodi.nimenees.com>, Eric Haszlakiewicz write
s:
>On Thu, Sep 01, 2005 at 05:18:20PM -0700, Bill Studenmund wrote:
>> On Thu, Sep 01, 2005 at 05:52:13PM -0500, Eric Haszlakiewicz wrote:
>> > On Thu, Sep 01, 2005 at 02:49:32PM -0700, Bill Studenmund wrote:
>> > > 
>> > > I'm not sure what I think of this. But I'll defer that for other message
>s. 
>> > > I am concerned that we may introduce more problems than we solve.
>> > 
>> > 	I think it makes the emul path stuff act more like a chroot
>> > environment.  The time when it might cause a problem is when that
>> > path gets fed to something outside the "chroot", i.e. a non-emul
>> > process.  It seems easier to think about solving issues wrt information
>> > moving across that pseudo-root boundary, than wrt inconsistent views
>> > of the filesystem within a single process depending on the syscall.
>> > 	However, I haven't actually come up with any concrete examples
>> > of problems/benefits; I was kind of hoping someone here would notice
>> > something obvious one way or the other. :)
>> 
>> Why is this a good thing? My gut instinct is that if we want a chroot, we
>> should chroot.
>
>	The more I think about it, the more I like that idea, but getting the
>overlay fs working right will probably be difficult.  Then there's various
>other details to worry about, like: does a non-emul process get to escape
>the chroot?  how about a different-emul one?  etc... This quickly becomes a
>much more significant task.

It's not a chroot, it's an overlay.  In fact, the particular case that 
raised this issue -- printing from acroread -- demonstrates this; a 
Linux progam is invoking a NetBSD native program.

We also have to deal with the implicit nature of the overlay (or 
chroot, if you prefer); we're not saying 'linux acroread', where linux 
is a setuid program that's doing the mount, invoking something, then 
cleaning up afterwards.  Both chroot and overlay pose security issues 
unless properly controlled -- which I think they are here, but we need 
to keep that in mind.

		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb