$topdir/.Trash and security

[David Faure]

On Sunday 05 September 2004 11:25, Mikhail Ramendik wrote:
> Hello,
> 
> Before releasing 0.3 I need to understand one thing.
> 
> It was proposed here that if the system sees an $topdir/.Trash , it
> should check its permissions (presumably for the sticky bit, and for n
> ot being a symlink), to avoid malicious attacks.
>
> But what should the system do if the partition does not support
> permissions at all, OR supports ACL and not the Unix model?

I think Alexander should have the authoritative answer on this (he has more
experience with creating trash directories on partitions...), but AFAICS:

* if the partition does not support permissions at all, like with FAT:
- either the uid used for mounting is the one of the user, and then the implementation
can safely create a ~/.Trash-$uid for him at the toplevel of the windows partition
- or the uid is different, and the security checks won't allow creating a trash directory.
Basically, the lack of permissions and the ownership are mapped to normal unix 
permissions (with one person owning the whole partition), so there's no special case here.

* About ACLs, I'm not sure why they are a problem.
In the case of .Trash/ I see no issue: if we can create a $uid subdir, then we know
there's no special ACL on it, so no problem.
And with an existing .Trash-$uid or .Trash/$uid, which could have ACLs granting 
other people to do things there, well, if we grant those permissions we know 
what they can do with it... Can't see any opportunity for an attack there.

David (who just implemented the new .trashinfo format, and the 
$XDG_DATA_HOME/Trash location).

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).