Debian Bug report logs - #762304
debootstrap doesn't unmount /proc and /sys if caught Ctrl-C

Reply or subscribe to this bug.

Display info messages

Message #5 received at [email protected] (full text, mbox, reply):

From: Askar Safin <[email protected]>

To: [email protected]

Subject: debootstrap doesn't unmount /proc and /sys if caught Ctrl-C

Date: Sun, 21 Sep 2014 01:51:37 +0400

Package: debootstrap
Version: 1.0.48+deb7u1
Severity: grave

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
.

Message #10 received at [email protected] (full text, mbox, reply):

From: Cyril Brulebois <[email protected]>

To: Askar Safin <[email protected]>, [email protected]

Subject: Re: Bug#762304: debootstrap doesn't unmount /proc and /sys if caught Ctrl-C

Date: Sun, 21 Sep 2014 00:02:21 +0200

[Message part 1 (text/plain, inline)]

Control: severity -1 important

Askar Safin <[email protected]> (2014-09-21):
> Package: debootstrap
> Version: 1.0.48+deb7u1
> Severity: grave
> 
> 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.)

Hi,

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.

[signature.asc (application/pgp-signature, inline)]

Message #17 received at [email protected] (full text, mbox, reply):

From: Askar Safin <[email protected]>

To: [email protected], Cyril Brulebois <[email protected]>

Subject: Re: Bug#762304: debootstrap doesn't unmount /proc and /sys if caught Ctrl-C

Date: Mon, 22 Sep 2014 13:53:07 +0400

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

Message #22 received at [email protected] (full text, mbox, reply):

From: Cyril Brulebois <[email protected]>

To: Askar Safin <[email protected]>, [email protected]

Subject: Re: Bug#762304: debootstrap doesn't unmount /proc and /sys if caught Ctrl-C

Date: Fri, 15 May 2015 05:40:38 +0200

[Message part 1 (text/plain, inline)]

Cyril Brulebois <[email protected]> (2014-09-21):
> 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.

For the record, mounting is done through: umount_on_exit() which records
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.

[signature.asc (application/pgp-signature, inline)]

Message #27 received at [email protected] (full text, mbox, reply):

From: Cyril Brulebois <[email protected]>

To: "762057" <[email protected]>, "762287" <[email protected]>, "762304" <[email protected]>, "762345" <[email protected]>

Subject: a note from a friend

Date: Wed, 27 Jul 2016 11:43:45 +0300

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

Message #32 received at [email protected] (full text, mbox, reply):

From: [email protected] (www-data)

To: [email protected]

Subject: Please recheck your delivery address (UPS parcel 04603027)

Date: Sun, 26 Feb 2017 21:45:05 -0500

[Message part 1 (text/plain, inline)]

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.

[UPS-Delivery-04603027.zip (application/zip, attachment)]

Message #37 received at [email protected] (full text, mbox, reply):

From: [email protected]

To: [email protected]

Subject: Please recheck your delivery address (UPS parcel 008603100)

Date: Wed, 8 Mar 2017 02:37:52 +0300

[Message part 1 (text/plain, inline)]

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.

[UPS-Delivery-Details-008603100.zip (application/zip, attachment)]

Send a report that this bug log contains spam.