[linux-user-chroot] README: Various updates

[Colin Walters <walters src gnome org>]

commit 1ab0cc3bc401c8e5578dd1da05aed502544e5183
Author: Colin Walters <walters verbum org>
Date:   Fri Jun 5 07:49:52 2015 -0400

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