Message-ID: <20192.65168.140290.462594@quad.stoffel.home>
Date:	Thu, 8 Dec 2011 13:14:40 -0500
From:	"John Stoffel" <john@...ffel.org>
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

>>>>> "Colin" == Colin Walters <walters@...bum.org> writes:

Colin> On Wed, 2011-12-07 at 14:36 -0500, John Stoffel wrote:
>> >>>>> "Colin" == Colin Walters <walters@...bum.org> writes:
>> 
Colin> I've recently been doing some work in software compilation, and it'd be
Colin> really handy if I could call chroot(2) as a non-root user.  The reason
Colin> to chroot is to help avoid "host contamination" - I can set up a build
Colin> root and then chroot in.  The reason to do it as non-root is, well,
Colin> requiring root to build software sucks for multiple obvious reasons.
>> 
>> What's wrong with using 'fakeroot' or tools like that instead? 

Colin> I assume you mean
Colin> "fakechroot" ( https://github.com/fakechroot/fakechroot/wiki )

Nah, I'm a doofus and mis-remembered about how fakeroot works to just
fake 'root' access for installers and such.  

Colin> The answer is twofold:

Colin> 1) It's a pile of gross hacks that can easily be buggy, and will be
Colin> permanently trying to keep up with newer system calls.
Colin> 2) It's slower.  My edit-compile-debug cycle REALLY matters to me.  If
Colin> you're a developer, it should matter to you - it directly impacts your
Colin> productivity.

Sure I can understand that, but why does your compiler need to be in a
chroot'd area?  If you're doing a cross compile, then just change the
tool chain.

Colin> How much slower?  Okay, well I tried "fakechroot" from Fedora 15.  It
Colin> appears to break parallel make.  Which obviously already disqualifies it
Colin> from being a core part of my edit-compile-debug cycle.

Find.

Colin> But here's an example of a small autotools (~6000 significant lines of
Colin> C) project, of which running configure is by far the slowest part.  Note
Colin> 'metabuild' is a trivial script which wraps the
Colin> 'autogen.sh;configure;make' dance:

Colin> $ metabuild   # to prime the caches
Colin> ...
Colin> $ git clean -dfx
Colin> ...
Colin> $ time ostbuild-user-chroot --unshare-ipc --unshare-pid --unshare-net
Colin> --mount-bind /src /src --mount-proc /proc
Colin> --mount-bind /dev /dev / /bin/sh -c 'cd /src/test-project; metabuild'

So what does 'ostbuild-user-chroot' that a simple makefile into a
seperate build area (with source just where it is now) doesn't do for
you?  

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?  

Colin> So it almost exactly doubles...Oh, crap, I just remembered I
Colin> have ccache, so we're really only timing configure runs here.
Colin> Anyways, you get the point.  Doubling my compile time is bad.
Colin> And this is a relatively small project.

I guess I still don't understand why your compile setup requires/wants
a chroot'd area.  Just setup your toolchain without all that hassle.  

Colin> One of the best parts of Linux is the filesystem and VFS - it's
Colin> really amazingly fast compared to other OSes, especially if you
Colin> know how to use it.  Adding in layers of emulation and crap in
Colin> between the program and the filesystem takes that away.

I'm just pushing back because I think you're using a hammer to try and
drive staples or screws.  It sorta works but....

Feel free to ignore my objections, I'm not a core developer by any
means.  

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

Powered by blists - more mailing lists