- What does Cisco have against Quebec?
- Attrition.org nails another nitwit
- Diary of a deliberately spammed housewife
- Seven cloud-computing security risks
- 20 great Windows open source projects
News | Newsletters | Podcasts | Chats | Opinions | RSS Feeds | This Week In Print | IT Careers | Community | Reports | Downloads | Slideshows | New Data Center
Partner Sites:App Performance | On Demand Security | Networking Solution | SOA | Value of WDS
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.
IBM spent all that money on a mass rollout of PGP Whole Disk Encryption, just when its discovered that...- Anonymous
Partner Content
CA Network & Voice Resource Center
Comprehensive Network & Voice Management Visit CA Network & Voice Management Resource Center and get insights into industry best practices, information that helps you to address your challenges.
CA Network & Voice Management Resource Center
Managing Voice Over IP for Successful Convergence
Voice over IP (VoIP) has much to offer in cost savings but some customers have concerns about VoIP call quality compared to the quality of traditional voice services. This white paper will help you learn how to take the right steps so that voice quality is assured.
Managing VoIP for Successful Convergence
The Changing Face of Network Management
Managing your network is serious business. This paper discusses the benefits of integrating configuration change-awareness into your network fault management solution
Download Whitepaper
Comment