debootstrap doesn't unmount /proc and /sys (on my Debian GNU/Linux) if caught Ctrl-C in unpacking stage.

I started debootstrap, then I changed my mind, pressed Ctrl-C and then decided to delete target (let's assume it is /tmp/wheezy). I typed "rm -r /tmp/wheezy", and then unexpectedly I saw the following:

rm: cannot remove `/tmp/wheezy/proc/asound/PCH': Operation not permitted
rm: cannot remove `/tmp/wheezy/proc/asound/card0/id': Operation not permitted
rm: cannot remove `/tmp/wheezy/proc/asound/card0/codec#0': Operation not permitted
[...]
rm: cannot remove `/tmp/wheezy/proc/1/mem': Permission denied
rm: cannot remove `/tmp/wheezy/proc/1/cwd': Permission denied
rm: cannot remove `/tmp/wheezy/proc/1/root': Permission denied
rm: cannot remove `/tmp/wheezy/proc/1/exe': Permission denied
rm: cannot remove `/tmp/wheezy/proc/1/mounts': Permission denied
[...]

This is very frustrating output. It is similar to output of the "rm -rf /*" command, so I was scared and I decided then I am deleting all my files. Then I discovered that the files are safe. (But I think this is possible that "rm -r /tmp/wheezy/proc /tmp/wheezy/sys" somehow damages host system.)

So, please, fix this bug. I gave it severity "grave" because:
1. Output of "rm -r /tmp/wheezy" makes a user very scared.
2. "rm -r" doesn't follow symbolic links. So, "rm -r /tmp/wheezy" (which includes "rm -r /tmp/wheezy/proc/1/root") fortunately didn't remove all files. But if "rm" did, then all files would be deleted.
3. debootstrap on my Debian GNU/Linux doesn't mount /dev, it mounts just /proc and /sys. But if it mounted /dev (via "mount --bind /dev /tmp/wheezy/dev" or via "mount -t devtmpfs devtmpfs /tmp/wheezy/dev"), then "rm -r /tmp/wheezy" would do "rm -r /tmp/wheezy/dev" and this would erase /dev on the host system (including /dev/null) and this would make the system unstable and it would probably crash.

So, as you can see, this bug is very close to make serious problems to whole system or even to data loss. Moreover, this is possible that this bug really cases crashes or data loss on other arches (for example, kFreeBSD or Hurd), for example, because they mount /dev or something like that.

Command, which reproduces the bug:
debootstrap --variant=minbase wheezy /tmp/wheezy http://localhost:3142/debian

Host is wheezy.

==
Askar Safin
http://vk.com/safinaskar
Moscow, Russia
Moscow State University, http://msu.ru , Faculty of Mechanics and Mathematics, Department of Mathematical Logic and Theory of Algorithms
.

Askar Safin <safinaskar@mail.ru> (2014-09-21):

and thanks for your report.

Well, debootstrap mostly performs the initial bootstraping, so I don't
think it would be introducing things like bind mounts which would then
endanger the root filesystem.

While it probably isn't too difficult to catch signals and do some
clean-up like unmounting filesystems, I don't think failing to do so
is a serious bug (important at most), and I'm lowering the severity
accordingly.

FWIW/IMHO: deciding to remove a chroot should always be accompanied
with checking (bind-)mounted filesystems.

Mraw,
KiBi.

Also, users just don't know that debootstrap mounts some file systems internally.
User starts debootstrap, stops it, then removes target. He has no way to guess that debootstrap mounted some file systems. Man page doesn't say anything about it. (And if the man page said about it, then there is still a problem, because users don't read documentation.)
Yes, debootstrap designed for experienced users which read documentation. But we should throw away this assumption when we talk about real user problems such as data loss.
Is there is any possibility that some program may cause data loss then we should do as much as possible to fix this bug absolutely for all users even for dummy ones.

==
Askar Safin
http://vk.com/safinaskar
Moscow, Russia
Moscow State University, http://msu.ru , Faculty of Mechanics and Mathematics, Department of Mathematical Logic and Theory of Algorithms

Cyril Brulebois <kibi@debian.org> (2014-09-21):
the specified filesystems to be unmounted in the UMOUNT_DIRS variable,
and adds the umount_exit_function() function to the list of things to
perform on exit, though an on_exit() call.

The following traps are put into place:

    trap "exit_function" 0
    trap "exit 129" 1
    trap "error 130 INTERRUPTED \"Interrupt caught ... exiting\"" 2
    trap "exit 131" 3

Then, exit_function() walks through the actions stored as EXIT_THING_*
by on_exit(), among which is the umount_exit_function() mentioned
earlier.

I'm not sure it would be reasonable to perform all EXIT_THING_* actions
in the interrupted case. I suspect a possible way to implement this
change would be to have an interrupt_function which would iterate over
items stored in UMOUNT_DIRS. If that's possible, that would still be a
bit unsatisfactory to have a direct call from there instead of a call
registered as done in the exit case, but that would avoid the need for
reimplementing the EXIT_THING_* handling…

Mraw,
KiBi.

Hello friend,

I wanted to  tell you  something but please make sure  that  no one finds  aout  about  this.  Please read the note  here <http://result.skateboardingacademy.com/e5jlazwy>

Sent from my iPhone, Cyril Brulebois

6001

Dear Customer,



We can not deliver your parcel arrived at February 25.



Please check the attachment for details!



Sincerely yours,

Tony Garrett,

UPS Chief Operation Agent.

Dear Customer,

We can not deliver your parcel arrived at March 05.

You can download the shipment label attached!

Thank you for your time,
Lester Thomson,
UPS Chief Support Manager.