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=
ages.=20
> > > I am concerned that we may introduce more problems than we solve.
> >=20
> > 	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. :)
>=20
> 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.
>=20
> I guess I wouldn't mind if we did something where /emul/linux/ disapeard=
=20
> and / turned into /../ or something like that.
>=20
> I'll be honest, I am not dead set against this. Concerned, but not dead=
=20
> 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
    behaviour.

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?

eric