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

On Mon, Sep 05, 2005 at 04:14:01AM +1000, matthew green wrote:
>=20
>    On Sun, Sep 04, 2005 at 04:02:52AM +1000, matthew green wrote:

>    > i'm really against using special mount points or chroots to get
>    > emulations working.  it's not clear it can be done well or safely
>    > and it adds extra work for the sysadmin to support emulations.
>    > it shouldn't need any more help that having /emul/linux populated.
>   =20
>    	IMO, using a consistent and well known approach to modifying how the
>    filesystem appears to a process would go a long way towards improving
>    safety by allowing the sysadmin to think about the behaviour of emul'd
>    processes in a way that he's probably familiar with due to setting up
>    chroot environments for things like named, ftpd, etc...

If we were starting from scratch, maybe. But we've had emulations working=
=20
like this for what now a decade? For better or worse, we know how to make=
=20
things work now. There are warts, but we know them.

>    	Setting up linux emul _already_ requires changes to fstab to
>    mount procfs.  I think the benefit of having the altered view of the
>    filesystem in /emul explicitly configured and having the results of
>    that _visible_ to the system admin even when using non-emul'd programs
>    outweighs the drawback of needing to take an extra step to configure
>    the mount.
>=20
> "an extra step"?  it also involves using a layered file system and
> some of us are still scared of using those in any way except r/o.
> it has an implicit chroot() component which the security side of me
> is screaming "BAD BAD BAD".

I disagree with Matt about the vulnerability of layered file systems, but=
=20
I strongly agree that I do not think that unionfs was designed for this.=20
It was designed for making CDs writable, and it does a fine job of that.=20

Among other things, unionfs will need to duplicate directories in its tree=
=20
for each directory in the underlying file systems. And we will end up with=
=20
three vnodes for each file or directory (lower, upper, and union).

Now say we have multiple emulations. We now have multiple mount points and=
=20
it all gets messy. :-|

Further, layered file systems do not yet handle mountpoints correctly. A=20
layered file system will blithefully build an upper vnode and end up=20
ignoring the mount point, and permit wandering under the mount point in=20
the underlying file system.

Take care,

Bill

--mvpLiMfbWzRoNl4x
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQFDHlzPWz+3JHUci9cRAk8EAJ9KQUI5MbgAVxtcWnS79infrYTxtQCdEj08
sEtOIqtX0Ih3zJ0QPyLucds=
=fRKI
-----END PGP SIGNATURE-----

--mvpLiMfbWzRoNl4x--