--ibTvN161/egqYuK8
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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, =
we
> > should chroot.
>=20
> 	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=
=20
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=
 a
> much more significant task.
>=20
> > Yes, the semi-chroot we have has issues, but I think we will run into m=
ore
> > 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/ disapear=
d=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. :-)
>=20
> Let see if enumerating the cases affected by this change brings
> anything to light:
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> 	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.
>=20
> 	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?

Take care,

Bill

--ibTvN161/egqYuK8
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQFDGJahWz+3JHUci9cRAiI8AJ9pkHNALz/igiLgcPkVNhp0vhmvdgCfe/H0
1HVlRh1CH7PMD+viJWu3P+U=
=oKXC
-----END PGP SIGNATURE-----

--ibTvN161/egqYuK8--