Re: ext4 features

[Bodo Eggert]

Lew Palm <lew@xxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/