Bug#369626: [Buildd-tools-devel] Bug#369626: schroot: rm -rf in file chroot cleanup destroys real /home if umount fails

[Roger Leigh]

tags 369626 + confirmed

Andreas Bombe <aeb at debian.org> writes:

> The session cleanup in 10mount ignores failures of umount invocations
> and cleanup continues.  In the case of file chroots with a /home bind
> mount that failed to umount, the rm -rf in 05file blindly descends into
> the system /home with obvious unpretty results.

I'm awfully sorry if this caused you to lose any data.

> The bind mount may fail to umount whenever something gets mounted under
> the bind.  In my case I was foolishly trying to rbind instead of bind
> /home in 10mount because my $HOME is a separate mount, and I wanted to
> have it available in the chroot.

I would like to use rbind, but this currently unsupported.  Please see
#354344 and #354298.

> Apart from making a failed umount abort the session cleanup, I see as
> another possible solution to rm -rf only a bind mount of the chroot to
> be sure there are no sub mounts, then umount this and only rmdir the
> actual chroot.  This would fail harmlessly if umounts failed (results
> only in a leftover session to be manually cleaned up).

There are a few possibilities here.

1) 10mount should exit with an error if umount fails.

   Caveat: if the session is ended with the setup scripts having
   failed, this would require manual cleanup by the system admin.
   This needs additional work in session::setup_chroot() in
   sbuild-session.cc, so that the session is not ended if the scripts
   fail.  This means not removing the session file from
   /var/lib/schroot/session/ on failure.

   Currently, because of the above consideration, the "setup-stop"
   phase of the session scripts can not fail.

2) 05file must check if any filesystems are mounted under the chroot
   root before running rm -rf.  Is there a portable and reliable way
   of doing this?  Would

     if mount | grep "$CHROOT_MOUNT_LOCATION"; then
       :
     else
       rm -rf "$CHROOT_MOUNT_LOCATION" || true
     fi

   be sufficient?

Due to the seriousness of the problem, I think both protective
measures should be implemented.


Regards,
Roger

-- 
Roger Leigh
                Printing on GNU/Linux?  http://gutenprint.sourceforge.net/
                Debian GNU/Linux        http://www.debian.org/
                GPG Public Key: 0x25BFB848.  Please sign and encrypt your mail.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/buildd-tools-devel/attachments/20060531/9252a862/attachment.pgp