User: Password:
Subscribe / Log in / New account

Secure deletion and trash bin support

Secure deletion and trash bin support

Posted Dec 7, 2006 20:32 UTC (Thu) by jzbiciak (subscriber, #5246)
In reply to: Secure deletion and trash bin support by bronson
Parent article: Secure deletion and trash bin support

I suppose it'll need to be a mount option in addition to a kernel feature. Even then I'm not sure it's perfect. For instance, what if /tmp isn't in its own filesystem?

Granted, it's a per-file attribute, so you have to remember to set it before you make a mistake anyway. Perhaps the attribute should be inherited from the current directory, one could set things up hierarchically? "I want undelete available in this tree, but not that one."

(Log in to post comments)

Secure deletion and trash bin support

Posted Dec 7, 2006 21:03 UTC (Thu) by oak (guest, #2786) [Link]

> I suppose it'll need to be a mount option in addition to a kernel
> feature.

Yes, there would need to be .trash dir for each file system...

Secure deletion and trash bin support

Posted Dec 7, 2006 21:17 UTC (Thu) by jzbiciak (subscriber, #5246) [Link]

I'm saying that I might simply not want a .trash directory in a particular filesystem *ever*. For instance if I have an FS that I use for large temporary files, I don't think it should get a .trash, ever.

trash bin

Posted Dec 8, 2006 19:23 UTC (Fri) by giraffedata (subscriber, #1954) [Link]

Presence of a .trash directory (a filesystem option) and a mount option are two different things, both valuable. In reality, I think users wouldn't be satisfied with undeletion without an entire storage management policy capability. The decision whether to delete a file as soon as the last normal reference disappears or keep it around in the trash needs to be based on what directory, filesystem, and mount the file was in as well as its name, and various attributes such as owner, size, and modification time.

But to make something mildly useful to some people, just a filesystem option (probably simply the existence of the .trash directory in its root) would be reasonable.

I don't even think the per-file attribute would be useful in a system that simple -- I don't know how the designers of the system in question envision that getting set.

Secure deletion and trash bin support

Posted Dec 8, 2006 1:11 UTC (Fri) by nix (subscriber, #2304) [Link]

Great. I guess I'd better point out some of these DoS scenarios...

Given users a and b, in group C, where (all paths filesystem-relative):

/ is writable by user a, with the sticky bit on, and readable and
executable by everyone (of course).
/bar is writable by group C.
/baz is writable by user b only, and not readable by anyone else.
/foo is writable by user x, who is known to be a bit of a mischievous sod,
and not by user b.

User b deletes a file in /bar. Now presumably /.trash inherits its
permissions from /, right? Well, that file's just gone into /.trash, which
*b cannot delete files from*. So now user b can fill up the disk just by
creating and deleting files, but has to appeal to a to fix things.

Worse, files b delets in /baz can only be deleted from /.trash by user a,
even though user a *cannot delete them from /baz in the first place*.

But it gets nastier. What if user a deletes an important file and then
user x spots this and immediately afterwards deletes a file with the same
name from /foo? Does that file overwrite the important file in /.trash? Do
the files in /.trash get the directory name encoded in their filename
somehow, to evade this? (If so, that means you can break the system in
another way: the encoding for filenames must, if not ambiguous, sometimes
be longer than the filenames themselves. Thus it's possible to produce a
file in a deeply-nested directory which has a name which is too long, when
encoded, to be written to /.trash.)

Another scenario: user b deletes an important file out of /baz: it was
group-readable, but what the hell, it's in a directory they can't read
anyway. But now it's been deleted, that is no longer true: now user x can
read it. Worse, user x can hardlink it into his own directory, and b can't
do anything about it: can't even delete it again. However, it is possible
depending on the semantics of repeated deletion that he may be able to
*overwrite* it by deleting another file with the same name (in which case
deleting symlinks seems risky, as that's opened up an rm variant of the
classic symlink attack: delete a symlink to /etc/passwd, wait for root to
delete a file with the same name, oops: worse, an attacker with write
privs in /.trash can delete anyone's file by hardlinking it into /.trash
under a suitable name and waiting for someone to delete a suitable file:
no, overwriting is not safe, you must unlink()).

And then what happens if you flip on the immutable bit for files
in /.trash?

So now we have rm(1) not consistently trashing files, possibly leading to
unreadable-by-others files becoming readable by them and unremovable by
you, or alternatively leading to arbitrary files that happen to have
symlinks pointing to them or happen to have been hardlinked into or out
of /.trash being overwritten.

This proposal needs a *lot* of thought. Either /.trash is fantastically
magical and violates most Unix rules for file access (hardlinks out of and
into banned, *symlinks* out of and into banned, always 1777 except that
files belonging to other users don't appear, um, how will that work
exactly?) or you've opened a vast can of worms.

(A plan9-style per-user /.trash bind-mount might work better, but the
userspace infrastructure for that is not really there yet.)

Secure deletion and trash bin support

Posted Dec 8, 2006 1:16 UTC (Fri) by nix (subscriber, #2304) [Link]

Actually, the .uid stuff prevents some of these attacks.

Just some. Not all :/

Secure deletion and trash bin support

Posted Dec 8, 2006 1:37 UTC (Fri) by liljencrantz (guest, #28458) [Link]

I've read through all your complaints about trash, and as near as I can tell, they fall in two categories:

* Problems that are solved by the /UID/ indirection
* Problems that are solved by not changing the access permissions or ownership of the file when moving it to trash.

If I have missed any cases, please point them out to me.

Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds