Trash: directories in $topdir, and security

Alexander Larsson alexl at
Fri Sep 3 10:47:40 EEST 2004

On Fri, 2004-09-03 at 00:44 +0400, Mikhail Ramendik wrote:
> Hello,
> On the matter of directories in $topdir, I think we have two options at
> this point:
> (a) $topdir/.Trash/$uid only, with .Trash getting created by the admin,
> and if it's not there, by the user. (If the creation fails, the user
> falls back to trashing to the directory in $HOME). 
> (b) $topdir/.Trash/$uid , but if .Trash is not there, the user creates
> ..Trash-$uid .

I'm for (b).

> I have seen letters in support of both; but I have failed to understand
> from the discussion why (b) is better (even though I have read through
> the whole thread).
> But, I have just had a thought. There seems to be a security-related
> drawback in the entire .Trash idea. What if a malicious user creates
> ..Trash with wrong permissions (i.e. the sticky bit is not set) ? Or even
> as a symlink to some other partition wholly under his control, i.e. one
> with a permissionless file system like FAT, or a removable device? What
> do we do about this?

What we do is that we define the exact permissions of .Trash (i did so
in an earlier mail) and refuse to use it if its not right.

> To avoid this, .Trash-$uid might work - but what if the permissions on
> $topdir don't allow the users to create these directories?

Then we trash by copying to $home or refusing to trash (implementation

> Note that option (b) won't resolve this problem, because if a malicious
> user does create .Trash, other users' software will still use it.

Only if we trust the .Trash dir to be right without checking it.

 Alexander Larsson                                            Red Hat, Inc 
                   alexl at    alla at 
He's a war-weary shark-wrestling filmmaker with a secret. She's an elegant 
winged schoolgirl from a different time and place. They fight crime! 

More information about the xdg mailing list