Bug#997960: Debspawn deletes anything mounted in a container

2021-11-08 Thread Matthias Klumpp
Hi Sam!

Am Mi., 27. Okt. 2021 um 21:24 Uhr schrieb Sam Hartman :
>
> Package: debspawn
> Version: 0.5.0-1
> Severity: serious
> Justification: Significant data loss
>
> I used debspawn interact to  interactively explore what I needed to do to get 
> a new upstream package building.
> To make that easier, I mounted my source trees and debian working environment 
> in the container.
>
> On exit, debspawn deleted everything.
> In retrospect, I can understand why this is, but it's pretty hostile to the 
> developer.
> I might be alone, but I find it very helpful to mount various things into 
> containers when exploring why things don't work.

Ha! First of all, I'm very sorry for this issue, and I hope this
didn't cause any bigger problems or a long recovery session.
Debspawn does not really expect users to mount things as well behind its back...
Bindmounts are evil sometimes, but ever since I deleted my whole root
filesystem by accident, I became a lot more careful :-D

> My recommendation would be to check for bind mounts and make sure they can be 
> unmounted before cleaning up.

That is actually a rather annoying operation, as you need to parse
`/proc/self/mountinfo` or call `findmnt` on every directory in order
to not only find "real" mountpoints but also bindmounts.
I tried the latter option though, and on my system I could only
measure a slowdown of a few milliseconds, so that's IMHO perfectly
fine as safety measure.

> A fix that would have worked in my case but that may not generally be good 
> enough would have been to restrict the container deletion to one-file-system.

That wouldn't find bindmounts though, and I'd rather catch these too :-)
The new 0.5.1 release will have the change included and will just
unmount any directory mountpoints upon container deletion - if the
user decided to create mountpoints on *files*, deletion of those will
likely just fail, which is fine with me (no data is lost and the user
knows what (not) to do next time).

Please give it a test with some scratch directory though before using
this with important data - just in case! ;-)

Cheers,
Matthias



Bug#997960: Debspawn deletes anything mounted in a container

2021-10-27 Thread Sam Hartman
Package: debspawn
Version: 0.5.0-1
Severity: serious
Justification: Significant data loss

I used debspawn interact to  interactively explore what I needed to do to get a 
new upstream package building.
To make that easier, I mounted my source trees and debian working environment 
in the container.

On exit, debspawn deleted everything.
In retrospect, I can understand why this is, but it's pretty hostile to the 
developer.
I might be alone, but I find it very helpful to mount various things into 
containers when exploring why things don't work.

My recommendation would be to check for bind mounts and make sure they can be 
unmounted before cleaning up.
A fix that would have worked in my case but that may not generally be good 
enough would have been to restrict the container deletion to one-file-system.




-- System Information:
Debian Release: 11.1
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable'), (200, 'unstable'), (1, 
'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.14.0-3-amd64 (SMP w/8 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages debspawn depends on:
ii  debootstrap1.0.123
ii  python33.9.2-3
ii  python3-toml   0.10.1-1
ii  systemd-container  247.3-6
ii  zstd   1.4.8+dfsg-2.1

Versions of packages debspawn recommends:
ii  build-essential  12.9
ii  devscripts   2.21.4

Versions of packages debspawn suggests:
ii  sudo  1.9.5p2-3

-- no debconf information