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]

Date:	Thu, 08 Dec 2011 13:26:40 -0500
From:	Colin Walters <walters@...bum.org>
To:	John Stoffel <john@...ffel.org>
Cc:	LKML <linux-kernel@...r.kernel.org>
Subject: Re: chroot(2) and bind mounts as non-root

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.

--
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/