From 1ab0cc3bc401c8e5578dd1da05aed502544e5183 Mon Sep 17 00:00:00 2001 From: Colin Walters Date: Fri, 5 Jun 2015 07:49:52 -0400 Subject: README: Various updates - Note to use ostree-list for submissions - Link to Codethink's sandbox lib https://mail.gnome.org/archives/ostree-list/2015-June/msg00002.html - Talk more about how other build systems root setups work and why l-u-c is unique, etc. --- README | 48 +++++++++++++++++++++++++++++++++++------------- 1 file changed, 35 insertions(+), 13 deletions(-) diff --git a/README b/README index a107280..a4526e7 100644 --- a/README +++ b/README @@ -5,24 +5,40 @@ This tool allows regular (non-root) users to call chroot(2), create Linux bind mounts, and use some Linux container features. It's primarily intended for use by build systems. -Project information -------------------- +Contributing +------------ + +Currently, linux-user-chroot reuses +the https://mail.gnome.org/mailman/listinfo/ostree-list +mailing list. -There's no web page yet; send patches to -Colin Walters +Please send patches there. Why is this useful? ------------------- -For build systems, being inside a chroot ensures that the build isn't -picking up files it shouldn't be. This helps avoid the problem of -"host contamination", where e.g. we want libfoo.h from inside our -root, not the one outside the root. - -Second, it helps avoid the fragility inherent in having to set up a -large set of environment variables pointing to our root (e.g. PATH, -LD_LIBRARY_PATH, XDG_DATA_DIRS, etc.). Once we chroot, PATH is just -the same as it normally is (/bin:/usr/bin). +There are a few well-known approaches for software build roots: + + - Set up a chroot as root, then chroot in, and become non-root + This is the model currently used by both rpm and dpkg. + The problem with this is that if you want to build *two* packages + where B depends on A, then the `%post` type scripts from A run + as root, and hence need to be fully trusted. + - Use `LD_PRELOAD` emulation + This is implemented by https://github.com/wrpseudo/pseudo + The problem with this is that it's a speed hit, and maintaining + that sort of emulation is a long-term maintenance pain. + - Don't do any chrooting, use environment variables + This is implemented by `jhbuild`. The problem with this is there + are a *lot* of these, and it's really easy to get "host contamination", + where we silently pick up `/usr/include/foo.h` instead of the one + from the root. + +What linux-user-chroot does is a variant of the first, except instead +of using root-owned files for the chroot, you simply make the chroot +data as non-root, and run `%post` type scripts as non-root too. + +This works because we believe linux-user-chroot is secure; see below. Security -------- @@ -99,3 +115,9 @@ This binary can be installed in two modes: 1) uwsr-xr-x root:root - Executable by everyone 2) uwsr-x--- root:somegroup - Executable only by somegroup + +Programs using linux-user-chroot +-------------------------------- + + - https://github.com/CodethinkLabs/sandboxlib + - https://git.gnome.org/browse/gnome-continuous/ uses it for builds -- cgit v1.2.1