Re: Managing users and groups within multiple devel chroots.

[Daniel Jacobowitz <dan@debian.org>]

On Thu, Sep 15, 2005 at 06:29:12AM -0500, Peter Samuelson wrote:
> 
> [Ernestas V.]
> > Perhaps hard/symlinking original /etc/passwd, /etc/shadow and
> > /etc/group to chrooted environments would help?
> 
> Symlinks won't work.  Think about what a chroot environment *is*.
> 
> Hardlinks will only work if the programs that edit /etc/passwd and
> /etc/group overwrite them rather than copy / unlink.
> 
> Bind mounts will work
> (mount --bind /etc/passwd /mnt/sarge-chroot/etc/passwd)
> but apparently don't support locking all of a file's representations,
> so you would need to be careful not to run adduser in multiple chroots
> at once (like doing several dist-upgrades in parallel, or having users
> log in to different chroots and all try to change their passwords at
> once).

Ooh ooh, an excuse to share my new toy...

I was setting up a chroot a couple of weeks ago and wanted it to
reflect my system configuration.  So the first thing I tried were bind
mounts for shareable directories - /home, /tmp, /etc, et cetera.  There
are a couple of problems with this for /etc.  The biggest one, for me,
was that the chroot was i386 and the base system was amd64.  Which in
itself works fine, except it points out one of those files which can't
be shared in this way: ld.so.cache.  And if you bind mount a different
ld.so.cache on top of the bind mounted /chroot/etc, then you can no
longer rename /etc/ld.so.cache - this has to do with the way the Linux
VFS works, as I understand it.

So I took FUSE, and the included demo which proxies one filesystem to
another location.  And I hacked it to support bringing specific files
from other locations, based on name.  It's not the most robust thing in
the universe - FUSE is not "good enough" to share / this way, things
just won't work right.  By "good enough" I don't know whether the
limitations are in FUSE or in the nature of what I was trying to do,
though.  And don't try this on /proc or /dev.  But for /etc, it works
well enough for 32-bit firefox and OpenOffice.org.

I've got the feeling this could handle flock() locking correctly, but
doesn't - does FUSE even implement that?  Anyway it should be fine
for /etc/.pwd.lock.

Here's the code, hardcoded paths and all:
  http://return.false.org/~drow/fuse/shadow-etc.c

-- 
Daniel Jacobowitz
CodeSourcery, LLC