linux-kernel - Re: chroot(2) and bind mounts as non-root

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.02.1112090143210.5366@aurora.sdinet.de>
Date:	Fri, 9 Dec 2011 01:49:35 +0100 (CET)
From:	Sven-Haegar Koch <haegar@...net.de>
To:	Colin Walters <walters@...bum.org>
cc:	John Stoffel <john@...ffel.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: chroot(2) and bind mounts as non-root

On Thu, 8 Dec 2011, Colin Walters wrote:

> On Thu, 2011-12-08 at 13:14 -0500, John Stoffel wrote:
> 
> > Or is it because you're trying to edit on one OS, such a fedora 14,
> > then build and debug inside an Debian 5.0 setup?  But without running
> > a completely seperate system, but just doing a chroot into a new
> > filesystem tree?  
> 
> Yes, something like that; basically it's about ensuring that the libfoo
> we're building binaries against is /home/walters/build/libfoo.so and
> not /usr/lib/libfoo.so.
> 
> I'm actually intending for the core build system of my OS to work in
> *both* cross and native compilation.  That means it's important to keep
> them as close as possible.
> 
> What you were talking about above (i.e. "just don't chroot") is what
> http://buildroot.net does (and others, I also semi-maintain GNOME's
> jhbuild).  It works if you're very careful in your build scripts, know
> and carefully propagate the large set of magic environment variables,
> etc., then yes, you can do it.
> 
> But chroot is just so nice a hammer for this nail.

For Debian there is schroot ("securely enter a chroot environment"), 
which nicely encapsulates entering pre-prepared chroots as a user (with 
a suid root program), setting up bind mounts, etc etc, and in the end 
landing inside the chroot as the calling user (if you have the 
permissions).

I use this to have build environments for a couple old older Debian 
releases and both 32+64 bit available on a single 64bit machine.

Source is available at git://git.debian.org/git/buildd-tools/schroot.git

Can't think of it only working on a Debian - maybe give it a try.

c'ya
sven-haegar

-- 
Three may keep a secret, if two of them are dead.
- Ben F.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/