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

[Roger Leigh]

On Mon, Feb 01, 2010 at 09:22:00PM +1100, Hamish Moffatt wrote:
> Package: schroot
> Version: 1.4.0-1
> Severity: critical
> Justification: causes serious data loss
> 
> I upgraded schroot from 1.2.3-1+b1 to 1.4.0-1, which wanted to replace
> some config files, which I have customised. I declined, intending to fix
> it later.

OK.  This shouldn't be an issue, since they haven't changed that much,
and the changes /should/ be forward-compatible.  However, it's
possible, at least in theory, that a mixture of old and new files could
interact badly and do this.  But, I must stress that the scripts
already have a certain level of sanity-checking built in to prevent
anything bad happening to the host.

> I started an schroot into an old sid 32-bit chroot (from my sid 64-bit
> host), and didn't notice any error messages, but found I was still
> running 64-bit binaries. I think the actual chroot() failed.

If you run with the additional options '-v --debug=notice', you should
get a much more detailed log of what schroot is doing, including every
file copy.  This should tell you what's going wrong.

> Later after exitting, I found that a bunch of files in /etc were now
> empty: passwd, group, shadow, hosts, protocols, services.

Firstly, many apologies for schroot losing your data.  The new version
has had several months of testing before going into unstable, and this
is the first dataloss bug I've seen.

This is really strange.  Could you please check a few things for me?

Firstly, in /etc/schroot/setup.d/00check at the bottom, there's a
check that CHROOT_PATH is defined and NOT '/'.  This to make sure any
subsequent scripts don't scribble over the host filesystem if it's
not been defined.  Is this still present?  This sanity check should
never ever trigger unless there's a schroot bug or configuration
error.

Now, the files you report empty are all NSS database files.  In
schroot 1.2.x, these were copied in by the 20copyfiles script, using
the file list in COPYFILES (script-config->script-defaults).  In
1.4.x, this is done by the 20nssdatabases script which uses getent(1)
which allows copying of all NSS data, irrespective of source, e.g.
db, nis, ldap etc.  This uses the NSSDATABASES option to specify the
databases to copy.  Was resolv.conf also affected?

Next, in /etc/schroot/setup.d/20copyfiles, is the copy code using
CHROOT_PATH to copy?  This script is most likely the cause of your
problems.  Alternatively, /etc/schroot/setup.d/20nssdatabases is
the other possible culprit, and the same question goes here.

I suspect it's a combination of your mixed old/new configuration,
*but*, the 20copyfiles should redundantly copy into the chroot
without any negative effects.  Neither of these scripts should
*ever* do anything untoward with the host under any circumstances.

It might be helpful to have a copy of all the dpkg cruft (dpkg-new,
dpkg-dist, dpkg-old etc), or even a tarball of your entire
/etc/schroot directory if possible to see what inconsistency
causes this misbehaviour.


Thanks,
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: 197 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/buildd-tools-devel/attachments/20100205/69f0fa18/attachment-0001.pgp>