summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorColin Walters <walters@verbum.org>2015-06-05 07:49:52 -0400
committerColin Walters <walters@verbum.org>2015-06-05 07:50:24 -0400
commit1ab0cc3bc401c8e5578dd1da05aed502544e5183 (patch)
tree05fd820cd23b4376817e6cb5ba9577fcaa905398
parent5d23708442b16138b800a4e4e9daf20eda50ba46 (diff)
downloadlinux-user-chroot-1ab0cc3bc401c8e5578dd1da05aed502544e5183.tar.gz
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.
-rw-r--r--README48
1 files 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 <walters@verbum.org>
+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