Subject: Re: printing with acroread7 and cups
To: Eric Haszlakiewicz <email@example.com>
From: Bill Studenmund <firstname.lastname@example.org>
Date: 09/02/2005 11:14:57
Content-Type: text/plain; charset=us-ascii
On Thu, Sep 01, 2005 at 10:19:15PM -0500, Eric Haszlakiewicz wrote:
> On Thu, Sep 01, 2005 at 05:18:20PM -0700, Bill Studenmund wrote:
> > Why is this a good thing? My gut instinct is that if we want a chroot, =
> > 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
Please note that we have an "overlayfs" file system that does NOT do what=
you want. So please be careful with your wording. :-)
> 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=
> much more significant task.
> > Yes, the semi-chroot we have has issues, but I think we will run into m=
> > of them if we lie like this. I also think part of it is I usually run=
> > linux apps outside of the /emul/linux area.
> > I guess I wouldn't mind if we did something where /emul/linux/ disapear=
> > 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.
Actually, no. It can also happen when the user was in such a directory=20
(from a NetBSD shell) and ran a Linux program. Say I'm looking at stuff=20
and I cd to /usr or /usr/bin or /etc. Then say I run a command that's=20
linux based. Voila, cwd for the linux command has a cwd that's outside=20
/emul/linux and mirrored. :-)
> 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.
Ok, I'm puzzled. What case did you actually make better?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)
-----END PGP SIGNATURE-----