[buildd-tools-devel] Bug#567932: Bug#567932: Bug#567932: Bug#567932: schroot: chroot failed, cleaned up my host /etc

[Roger Leigh]

On Sun, Jun 06, 2010 at 12:26:32PM +0100, Roger Leigh wrote:
> severity 567932 important
> thanks
> 
> On Thu, Feb 18, 2010 at 10:16:51AM +1100, Hamish Moffatt wrote:
> > On Wed, Feb 17, 2010 at 11:12:52PM +0000, Roger Leigh wrote:
> > > On Thu, Feb 18, 2010 at 09:41:17AM +1100, Hamish Moffatt wrote:
> > > > Here are the only files which were modified. I have since put in the
> > > > versions from 1.4.0-1 and customized those and schroot is working fine.
> > > 
> > > Many thanks, I'll look at these in more detail tomorrow.
> > > 
> > > Just to check, if you didn't upgrade the altered conffiles during the
> > > update, this left 10mount in its customised state with the replacement
> > > as 10mount.dpkg-new, and all the other setup scripts were updated?
> 
> I'm downgrading the serverity of this bug to "important".  Because there
> has been just the one reported instance of this bug, and we haven't as
> yet identified the cause, I think this is more appropriate.  I won't
> close it though--if we find out what in the scripts triggered this
> behaviour, I would like to add additional safeguards into the current
> scripts if that's possible.

Hi Hamish,

I now have an idea about what might have gone wrong (at the end of this
mail).  It would be great if you could let me know if this idea is
correct or not.

Looking at the 10mount script you provided, it looks like it originated
in version 1.1.5; this is the version which provides the most minimal
sensible diff:

--- bin/schroot/setup/10mount	2010-06-06 22:14:49.515889319 +0100
+++ /tmp/10mount	2010-06-06 22:10:40.783889915 +0100
@@ -1,5 +1,5 @@
 #!/bin/sh
-# Copyright © 2005-2007  Roger Leigh <rleigh at debian.org>
+# Copyright � 2005-2007  Roger Leigh <rleigh at debian.org>
 #
 # schroot is free software; you can redistribute it and/or modify it
 # under the terms of the GNU General Public License as published by
@@ -102,10 +102,12 @@
 
 	if [ "$CHROOT_TYPE" != "plain" ]; then
 	    do_mount "-t proc"    "proc"     "${CHROOT_PATH}/proc"
-	    do_mount "-o rw,bind" "/dev/pts" "${CHROOT_PATH}/dev/pts"
+	    #do_mount "-o rw,bind" "/dev/pts" "${CHROOT_PATH}/dev/pts"
+	    do_mount "-o rw,bind" "/dev" "${CHROOT_PATH}/dev"
 	    do_mount "-t tmpfs"   "tmpfs"    "${CHROOT_PATH}/dev/shm"
 	    do_mount "-o rw,bind" "/home"    "${CHROOT_PATH}/home"
 	    do_mount "-o rw,bind" "/tmp"     "${CHROOT_PATH}/tmp"
+	    do_mount "-o rw,rbind" "/srv"     "${CHROOT_PATH}/srv"
 	fi
 
     elif [ $1 = "setup-stop" ]; then

While this doesn't directly explain why the files got deleted, this
is a rather old version of the script and it may be the case that
it did make some assumptions which didn't hold for newer schroot
versions.  However, your script should still have functioned perfectly
well, and I don't think it's related unless you have some unusual
setup such as a symlink from /etc to some shared location under /srv.
I don't think this explains why the files *on your host filesystem*
got zeroed.  The only explanation I can think of there is that the
20nssdatabases script does this:

  dup_nss "$db" "${CHROOT_PATH}/etc/$db"

where dup_nss is simply

  getent "$1" > "$2"

Normally, this would boil down to

  getent passwd > /var/lib/schroot/session/$session/etc/passwd

This would also normally be OK.  The only circumstance where it could
delete the file is if /etc/passwd and
/var/lib/schroot/session/$session/etc/passwd *are the same file*.  i.e.
you have your root filesystem (or at least /etc) as the chroot
filesystem either mounted or bind mounted directly or as an
additional mount.  Could this possibly be the case with your setup?

In earlier versions where 20copyfiles copied the databases, we
checked if the file contents and/or inodes were the same so that
a file would never be copied on top of itself.  With 20nssdatabases,
the shell I/O redirection will zero the file prior to exec'ing
getent.  This means that getent will read and empty database file
(unless using NIS/LDAP etc.) and then have nothing to write.

But, this will only occur in the specific situation where the
root filesystem (or parts of it) are mounted inside.  While we
specifically check if / is used directly, it's quite possible to
bind-mount /etc.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/buildd-tools-devel/attachments/20100606/a51a5391/attachment-0001.pgp>