[Buildd-tools-devel] Bug#369626: schroot: rm -rf in file chroot
cleanup destroys real /home if umount fails
Andreas Bombe
bombe at informatik.tu-muenchen.de
Wed May 31 23:37:35 UTC 2006
On Wed, May 31, 2006 at 10:53:18AM +0100, Roger Leigh wrote:
> 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.
No worries, I suspected what happened and killed the rm and everything
that got deleted I had available elsewhere for restoring.
> 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.
If a umount fails it will require manual admin intervention anyway so
that wouldn't make much of a difference. Making the rm -rf safe is
still required in any case, I'd say.
> 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?
I don't think that is safe. It depends on all mounts being recorded in
/etc/mtab, which is not the case if something *inside* the chroot
mounted something, for example.
I thought about rm with a "do not cross filesystems" option, still that
wouldn't help because binds may well be on the same filesystem. There
are no usable criteria for using "find ... -exec rm ..." either.
The only way I know to be sure there are no submounts is to mount --bind
the chroot to a temporary location and rm -rf there, then unmount the
temporary bind and rmdir the chroot.
The rmdir will fail safely if the chroot isn't empty then. Even before,
the rm -rf of the temp bind will fail safely upon trying to remove an
empty directory used as a mount point in the chroot.
--
Andreas Bombe <bombe at informatik.tu-muenchen.de> GPG key 0x04880A44
More information about the Buildd-tools-devel
mailing list