Subject: Re: printing with acroread7 and cups
To: Bill Studenmund <email@example.com>
From: Eric Haszlakiewicz <firstname.lastname@example.org>
Date: 09/01/2005 22:19:15
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:
> > >=20
> > > I'm not sure what I think of this. But I'll defer that for other mess=
> > > 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.
> Yes, the semi-chroot we have has issues, but I think we will run into more
> of them if we lie like this. I also think part of it is I usually run=20
> linux apps outside of the /emul/linux area.
> I guess I wouldn't mind if we did something where /emul/linux/ disapeard=
> and / turned into /../ or something like that.
> I'll be honest, I am not dead set against this. Concerned, but not dead=
> set. So I'm willing to be convinced. :-)
Let see if enumerating the cases affected by this change brings
anything to light:
1) getcwd for any path not inside the /emul directory and non-existant
within /emul stays as is, so there is no change from existing
2) The case for when an emul-process is in a non-/emul path that also
exists under /emul is a bit weird:
This can only happen when an explicit chdir("/../foo") was done.
The new getcwd will return a normal path, so a emul-process chdiring
back to that directory will end up in the /emul directory.
However, any syscalls that access the filesystem do the emul-check
so as far as the emul-process is concerned it can't actually=20
effectively get to the non-emul directory even if that is its cwd.
If it's using an absolute path it can reference files using /../,
but that doesn't work for relative paths. Therefore getcwd should NOT
return /../foo so the files accessed through relative paths are the
same ones accessed by anything that builds a full path with
getcwd() + a filename.
The behaviour of the emul'd getcwd doesn't change here.
3) Directory within the /emul tree. New getcwd acts differently.
3a) When used entirely within the emul-process the de-emul'd path
works fine, since the emul-check throws any accesses of non-/emul
paths back into the /emul tree.
3b) Non-emul processes passing paths into an emul-process should
also work fine since the emul-process can use the /emul paths.
If it does a chdir then a getcwd the paths will be different
but that happens anyway if there's a symlink in the path.
A program that explicitly looks for those symlinks might get
confused, but I don't think that's very likely.
This is the case that breaks currently with acroread b/c
acroread does a chdir, getcwd, then uses that path to build
a new path to the file.
I believe this is also the case that affects realpath() when
called with a relative path.
3c) An emul-process passes a path out to a non-emul-process.
e.g. a shell script running under /emul/linux/bin/bash uses
the output of pwd to build an argument for pax (or anything
else which doesn't exist in /emul/linux).
This problem exists now to some extent, and having getcwd
adjust /emul paths will make it somewhat worse. I'm not
sure how much worse since I'm drawing a blank on an actual
example of when this happens.
Any cases I missed?