On Thu, Sep 01, 2005 at 11:24:37PM -0400, Steven M. Bellovin wrote:
> 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.

	_currently_ it's not a chroot, but it sure acts an awful lot like one.
If the /emul path stuff was implemented w/o all the wrapper syscalls that
just have CHECK_ALT_*, the easiest way to do it would be with a chroot.
If you just mount an overlay on / it's going to affect _all_ processes,
not just emul'd ones, so you need to mount it elsewhere and make that
be the root for emul'd processes.

> 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.

	My thought was the the overlay would be pre-mounted, just another
entry in fstab that caused something like
	mount_union -b -o 'special-emul-flag=linux' / /emul/linux
and only the chroot would occur automatically.  Of course the security
implications would need to be thought through, but "auto-chroot into /foo"
seems easier for an admin to think about than the rather vaguely defined
CHECK_ALT_* behaviour.

eric