Messages in this thread |  | | | Subject | Re: [PATCH] revert- sys_setaltroot | | From | David Woodhouse <> | | Date | Wed, 22 Dec 2004 11:45:22 +0000 |
| |
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@osdl.org> > To: "Seth, Rohit" <rohit.seth@intel.com>, Al Viro <viro@parcelfarce.linux.theplanet.co.uk> > Cc: Andrew Morton <akpm@osdl.org>, "David S. Miller" <davem@davemloft.net> > 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@osdl.org> > To: "Seth, Rohit" <rohit.seth@intel.com> > Cc: Andrew Morton <akpm@osdl.org>, Al Viro <viro@parcelfarce.linux.theplanet.co.uk> > 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |