Subject: Re: printing with acroread7 and cups
To: Eric Haszlakiewicz <erh@nimenees.com>
From: Steven M. Bellovin <smb@cs.columbia.edu>
List: tech-kern
Date: 09/01/2005 23:24:37
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