Messages in this thread | | | From | Bodo Eggert <> | Subject | Re: ext4 features | Date | Thu, 06 Jul 2006 00:40:58 +0200 |
| |
Lew Palm <lew@tzi.de> wrote: > Jeffrey V. Merkey wrote:
>> The old novell model is simple. When someone unlinks a file, don't >> delete it, just mv it to another special directory called DELETED.SAV. >> Then setup the >> fs space allocation to reuse these files when the drive fills up by >> oldest files first. It's very simple. Then you have a salvagable file >> system. > > A complete foolproof car is a car with a maximum speed of 0 mph. > As a user I give commands to my computer, for example an order to delete a > file. And this is what I expect it to do.
You don't delete a file but a filename, and that's what your system will still do.
> If I want it to move a file to another position in the filesystem, I would > use another command. I don't want my operating system to josh me, that's why > I use Linux. > Stealthy keeping of deleted files somewhere is a security black hole.
Depending on unlinked file to be inaccessible and never have been copied just because you called unlink is the real security hole.
> But accidents happen. Hardware perishes, users are making mistakes, sometimes > coffee is pouring... > That's why we backup important data regulary.
And the salvaging fs will do exactly this whenever you unlink() the final reference. You could also use a userspace library catching each unlink call, but it would also have to intercept each write() call for each user and try to reclaim the backup copies on disk-full and would-have-to-fragment events. Off cause there are no userspace-visible would-have-to-fragment events, so besides being ugly a userspace solution would not be able to completely provide the same service.
> A not-really-deleting-filesystem wouldn't relieve us of that duty, but would > make a system more insecure and ambiguous.
It's just a marginal shift. If you can't trust yourself, you've lost. If you can't trust the current root, you're screwed, too. If you can't trust a future root, the time window in which the file can be recovered will slightly increase and the needed knowledge will be reduced. Otherwise, there is no change. -- Ich danke GMX dafür, die Verwendung meiner Adressen mittels per SPF verbreiteten Lügen zu sabotieren.
http://david.woodhou.se/why-not-spf.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |