Trash: directories in $topdir, and security

[David Faure]

On Friday 03 September 2004 09:47, Alexander Larsson wrote:
> 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).

OK with me.

> > 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
> defined).
> 
> > 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.

OK with me.

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