[Pkg-privacy-maintainers] Bug#919405: nautilus-wipe: Bug #1: Ignores security setting. Bug #2: Cannot abort.

[Colomban Wendling]

On Tue, 15 Jan 2019 18:19:26 +0200 Svjatoslav Agejenko 
<svjatoslav at svjatoslav.eu> wrote:
>    * What led up to the situation?
> 
> I choose to wipe disk space on BTRFS formatted
> internal SSD or external flash drive. Same behavior in
> both cases. Have not tested on other filesystems.
> 
> I chose 1 for number of passes.
> 
> I did not chose "Fast and insecure mode".
> 
> I did not chose "Last pass with zeros instead of random data".
> 
> Then I click button "Wipe".
> 
>    * What was the outcome of this action?
> 
> I see new dd process appear in the process list that looks like this:
>  dd if=/dev/zero of=/media/.......... bs=8M conv=fdatasync
> 
> 
>    * What outcome did you expect instead?
> 
> 
> I did expect random data, not zero space fill.

What you are seeing is an artifact of libgsecuredelete's workaround for 
the underlying sfill tool ignorance of file system size limits and 
internal implementation [1].  Basically, what is happening is that large 
zero-filled files are created (to reduce the amount of free space), then 
the free space left (if any) is wiped with sfill, and finally the 
zero-filled files are deleted with srm using the options you selected.

This indeed adds an additional pass of zeroes on the free space, but the 
final result should still be what you expected (I'm not entirely sure 
for magnetic analysis, but I'd guess it should still be pretty close), 
albeit with an additional pass.

Unfortunately, something along those lines is required to support 
filling space larger than the FS's max file size, because of sfill 
limitations.  Without this for example filling 5Gb on a FAT32 FS would 
fail, and actually leave about 1Gb untouched.

[1] 
https://git.tuxfamily.org/wipetools/libgsecuredelete.git/tree/gsd-sfill-helper.sh.in

> Also I cannot cancel this operation. When I click cancel button
> I get popup asking to either pause or cancel. I click cancel,
> and popup window disappears but dd process continues in the background.

That should be looked into then, but a possible reason might be that 
filling might require root privileges but the controlling (user) process 
won't be able to affect root processes.

HTH,
Colomban