1

I want to delete a file on a linux ext4 file system such that the disk does not contain the name of the file anywhere on the disk (free space, file system metadata, or anywhere else).

For example, I don't want any trace that a file named "passwords.txt" was ever on the disk.

I have posted this question on superuser in a different form and no one has answered it successfully.

I'd prefer to use /usr/bin/shred. It works great for removing the data of a file, but the file's name is still visible on the disk. Here's how I'm testing it:

dd if=/dev/zero of=fs bs=1M count=300
hexdump -C fs   # verify it's empty
mkfs.ext4 fs
mkdir m
sudo mount fs m
sudo chown -R $USER m
cd m
echo secretkey > passwords.txt
cd ..
sudo umount m
grep secretkey fs   # <== shows up as expected
grep passwords.txt fs
strings fs | grep sec
strings fs | grep pass
sudo mount fs m
cd m
/usr/bin/shred -vuz -n 1 passwords.txt
cd ..
sudo umount m
grep secretkey fs   # <== does not show up, this is good
grep passwords.txt fs   # <== PROBLEM: filename still shows
strings fs | grep sec
strings fs | grep pass   # <== problem: still shows up
hexdump -C fs | grep sec
hexdump -C fs | grep pass

And here's the output from the mount command that shows some of the filesystem's modes:

type ext4 (rw,relatime,data=ordered)

More details for those interested:

Update 1:

Renaming the file from passwords.txt to something random like "asdfasdf.txt" before shredding it does not resolve the problem. When you run /usr/bin/shred in verbose mode you'll see that it goes through a series of file renames before it truncates/unlinks the file. I assumed that this was shred's way of securely removing traces of the file's name. Does the filesystem need certain modes enabled in order to support this? I'll copy/paste what shred's output looks like during the file removal:

/usr/bin/shred: passwords.txt: pass 1/2 (random)...
/usr/bin/shred: passwords.txt: pass 2/2 (000000)...
/usr/bin/shred: passwords.txt: removing
/usr/bin/shred: passwords.txt: renamed to 0000000000000
/usr/bin/shred: 0000000000000: renamed to 000000000000
/usr/bin/shred: 000000000000: renamed to 00000000000
/usr/bin/shred: 00000000000: renamed to 0000000000
/usr/bin/shred: 0000000000: renamed to 000000000
/usr/bin/shred: 000000000: renamed to 00000000
/usr/bin/shred: 00000000: renamed to 0000000
/usr/bin/shred: 0000000: renamed to 000000
/usr/bin/shred: 000000: renamed to 00000
/usr/bin/shred: 00000: renamed to 0000
/usr/bin/shred: 0000: renamed to 000
/usr/bin/shred: 000: renamed to 00
/usr/bin/shred: 00: renamed to 0
/usr/bin/shred: passwords.txt: removed
Vahid Pazirandeh
  • 121
  • 3
  • 1
    Why not simply rename it to something random and then delete it ? – Overmind Sep 23 '19 at 07:15
  • You might want to clarify the "anywhere on the disk" part of your opening sentence. Taken literally, that means that, if a user on the system looked at this webpage, you want all instances of the text "password.txt" to be scrubbed from their web cache/history. Given that this has no connection to the actual contents of the filesystem, I doubt that you actually mean that, but, if you do, then this becomes a much, much larger task, as it will require every sector of the entire disk to be examined. – Dave Sherohman Sep 23 '19 at 08:04
  • @Overmind, That is a good idea but unfortunately doesn't resolve the problem. I'll update the OP noting as such. – Vahid Pazirandeh Sep 24 '19 at 16:52
  • @DaveSherohman, I'm not totally following. Can you give me an example of what a better sentence would look like? thx – Vahid Pazirandeh Sep 24 '19 at 16:53
  • No, I can't suggest a better wording, because I don't know what you actually mean. If a different user (not you) on the system has a saved email which says "20 years ago, I heard about a guy in Russia who kept a list of passwords in a file named passwords.txt" - i.e., the text "passwords.txt" is on the disk, but has absolutely no connection at all to your expurgated file - do you care? If you do care, should that email message be edited ("...a file named XXXXXXXXXXXXX") or should the file containing the email message be deleted? – Dave Sherohman Sep 25 '19 at 07:44

1 Answers1

0

The filename is stored in the "directory" data structure which has "(string)filename" and the corresponding "(int) inode" values. The directory is responsible for mapping filename to inode and mapping the inode to sectors on disk. Filename is not saved on disk's sectors like the file content is.

File names and the directory structure have the following implications:

  • inodes do not contain file names, only other file metadata
  • directories are lists of association structures, each of which contains one filename and one inode number
  • the file system, when accessing data, must search the directory for a particular filename and then convert the filename to the correct corresponding inode number
  • a file rename that does not cross file system boundaries and it is just a metadata change, so it should preserve the inode number
  • on ext4 file system, the record of the name does affect the inode itself (with a change of the modification time), but still, the previous name is not stored anywhere

Therefore, renaming the file to something random should actually make the name gone for good, unless you have backup systems taking periodic backups in which case you will have to take care of these also.

Overmind
  • 3,076
  • 2
  • 16
  • 25
  • Thanks for all the helpful information here. However, renaming the file to something random does not solve the problem. I'll update the OP to explain a little more. Maybe there is a problem with my test methodology? Using a file-backed filesystem may be messing things up. When I get a chance I'll make a normal disk partition and re-run the test. – Vahid Pazirandeh Sep 24 '19 at 16:56