Subject: Using overlay+chroot for emul (Was Re: printing with acroread7 and cups)
To: Steven M. Bellovin <firstname.lastname@example.org>
From: Eric Haszlakiewicz <email@example.com>
Date: 09/02/2005 08:53:21
On Thu, Sep 01, 2005 at 11:24:37PM -0400, Steven M. Bellovin wrote:
> In message <20050902031915.GA15795@jodi.nimenees.com>, Eric Haszlakiewicz write
> >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
> >> > > 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