Kernel space: a kernel "trashcan" for rm-ed files

A look at the man page for the chattr command reveals some interesting functionality; users may set special bits on files to request either that the file be undeletable, or that deletion be "secure" - meaning that the file's contents truly disappear from the disk. The key word here, however, is "request." Those bits have existed for many years, but few - if any - Linux filesystems actually implement those features. The undeletable and secure deletion flags are just placeholders for a "would be nice" feature to be added in the future. Someday.

That day may be a little closer thanks to this patch posted by Nikolai Joukov. It adds support for those two flags to ext4 in a relatively simple and straightforward way.

The patch works like this: whenever the last link is removed from a file, the undeletable and secure deletion flags are checked. Should either one be set, the file will be moved over to the .trash/<uid>/ directory in the root of the filesystem. Each per-uid directory has restrictive permissions, keeping users from perusing each others' deleted files. There are no subdirectories, so the path information is lost; preserving paths might be added in a future version. A number is appended to the file name when collisions with files already in the trash happen.

That's it for the kernel side. Undeletion is easily handled from user space by simply moving the file back out of the trash. The secure deletion feature is also to be done in user space, however. A special daemon can overwrite the file data in whatever way best suits the user's paranoia, then delete the file for real. A possible addition to the patch is a notification mechanism to force that daemon to run when filesystem space gets tight. In any case, all of the policy decisions on how to handle secure deletion requests would live in user space.

One might wonder why the trash can needs to be implemented in the kernel. The desktop projects have, after all, had a trash can available for some time. There seem to be two reasons why this patch adds that functionality. The first is that it comes for free with this approach to secure deletion. More importantly, however: it is not really possible for a user-space solution to intercept every attempt to delete a file. The nicest file manager available will not be able do do anything about an "rm" command typed into a shell, or an unlink() call from within a non-cooperating application. Catching file deletion within the kernel ensures that none will slip through the cracks.

The patch has not received a whole lot of comments as of this writing. One question which has come up is: why not do this at the VFS layer, rather than within ext4? There is little that is ext4-specific about the patch, and doing the work within the VFS would make this feature available to all filesystems - at least those which support the relevant file flags. Mr. Joukov agrees that moving this feature up might be the right thing to do, so there may be a reworked version of this patch coming in the future.