Re: [PATCH] revert- sys_setaltroot

From: David Woodhouse
Date: Wed Dec 22 2004 - 06:47:49 EST


On Wed, 2004-12-22 at 03:03 -0800, Andrew Morton wrote:
> There were security problems and suggestions that a namespace-based
> approach would be better. umm, have a random sprinkle of emails:

Thanks.

> Begin forwarded message:
>
> Date: Tue, 19 Oct 2004 15:32:57 -0700 (PDT)
> From: Linus Torvalds <torvalds@xxxxxxxx>
> To: "Seth, Rohit" <rohit.seth@xxxxxxxxx>, Al Viro <viro@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
> Cc: Andrew Morton <akpm@xxxxxxxx>, "David S. Miller" <davem@xxxxxxxxxxxxx>
> Subject: RE: FW: [PATCH] Support ia32 exec domains without CONFIG_IA32_SUPPORT
>
>
>
> Hmm. Do we actually want to clear the alternate root? It looks like that
> would make altroot useless.
>
> Who uses it? I thought it was only really used for the emulation
> environments on sparc64 etc. And clearly now ia64. But not saving it
> across an exec would make it useless, no?

No, clearing the altroot doesn't make it useless. If we're executing
another non-native binary, the emulator will set the altroot again. This
isn't _supposed_ to be a chroot. It's mostly to keep the dynamic linker
happy, and resetting it on exec is fine. We were doing that anyway when
it was a function of the personality, because executing new binaries
also resets the personality.

I'm using it on ppc to run i386 binaries -- it's certainly not limited
to sparc64 and ia64.

> Begin forwarded message:
>
> Date: Fri, 22 Oct 2004 17:28:35 -0700 (PDT)
> From: Linus Torvalds <torvalds@xxxxxxxx>
> To: "Seth, Rohit" <rohit.seth@xxxxxxxxx>
> Cc: Andrew Morton <akpm@xxxxxxxx>, Al Viro <viro@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
> Subject: RE: FW: [PATCH] Support ia32 exec domains without CONFIG_IA32_SUPPORT
>
> On Fri, 22 Oct 2004, Seth, Rohit wrote:
> >
> > Could you please let me know how we should proceed with this issue so
> > that emulators can seemlessly support different execution domains.
>
> Well, my _personal_ preference by far is to use the equivalent of "chroot"
> for the emulated environment. So whenever you hit a x86 binary, you just
> chroot to /emul, and then you run it there.
>
> NOTE! I say "equivalent", because you could do it by creating a separate
> namespace instead, if you wanted to - and just overmounting /lib and
> /usr/lib with the emulation environment versions in that particular
> namespace.
>
> Also, note the bind mounts: if you do end up having "/emul", you want to
> have the local /lib and /usr/lib be there, but the rest would be just bind
> mounts back to the original root, making things pretty similar (ie people
> would still see all their normal files in their home directories etc, it
> would be just /lib that effectively gets swapped out).

I see the point but I'm not sure I understand in detail how this can
work with namespace. It's not just /lib and /usr/lib which exist in the
altroot -- we also need certain files from /etc too, while leaving the
rest of /etc as it was. Do we have to bind-mount just those specific
files? And can we arrange for the alternate namespace to be
automatically dropped on exec() too? And can we do this without needing
the interpreter to be setuid in all cases?

> Al may have more intelligent suggestions.

Hopefully :)

--
dwmw2

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/