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.

Whitepapers

• Selecting Effective Virtual Directories
• Best Practices for HP Servers and HP Enterprise Virtual Array in a Microsoft Exchange
• Compliance, Protection, Recovery: A Layered Approach to Laptop Security
• Endpoint Security: Data Protection for IT, Freedom for Laptop Users
• IT Departments on Data Security: A Research Concepts Survey
• Laptop Security Tool Helps Allina Hospitals Track 97% of IT Assets

View more SOFTWARE whitepapers

Webcasts

• Managing the End User Experience-A Real World Example of Success
• Lowering the Cost of Email Archives
• Google Webcast: Why archive email? Top challenges and best practices
• High Availability for SQL Server 2005 Using Array-Based Replication and Host-Based Mirroring Technologies
• Technical Overview of Exchange Server 2007 with HP Servers and Storage
• Bringing Order and Security to your Mobile Workforce: Corporate Mobility Policy and Device Management On-Demand

View more SOFTWARE webcasts

Special Reports

• Application Performance Management Executive Guide
• Executive Guide: Building a Service Oriented Architecture
• IT Buyers Guide To: Collaboration

View more SOFTWARE special reports