Trash mechanism

[David Faure]

On Friday 27 August 2004 08:38, Alexander Larsson wrote:
> On Thu, 2004-08-26 at 15:31, David Faure wrote:
> 
> > > > The user creating the .Trash directory would need to make it world-writable, right?
> > > 
> > > Yeah. We should probably also make it world unreadable and with sticky
> > > bit (like /tmp) so that you can't look at it, and rename or remove other
> > > peoples trash dirs. Of course, even with the sticky bit set the person
> > > who creates the .Trash dir can still rename/remove other users trash
> > > dirs. I dunno what to do about that.
> > 
> > Waldo suggested the following solution:
> > we should make a small suid-root program that creates $topdir/.Trash and 
> > $topdir/.Trash/$uid for the user calling that program. This solves the
> > problem you mention (deleting other people's $uid dirs) as well as another
> > similar problem (creating a $uid dir before the other user can do it, effectively
> > preventing him from doing it).
> > I suck at writing suid-root programs though - maybe this is something
> > you (or any other C programmer who volunteers) could look into? :/
> 
> I'm not sure having a setuid root program that can create directories
> everywhere is a good idea. However, maybe we can have one that does the
> chroot and sets the right permissions.
I guess you mean s/chroot/chown/.  Yes, of course: the idea was a program
that can *only* create $topdir/.Trash/$uid, not any directory anywhere.
But Lars Hallberg is right, this could allow filling partitions (although, well,
one can fill the mailspool by sending himself a huge mail, too, unless there
are mail quotas). It would have to be configurable indeed.

Hmm, discussing this with other people here brought up again the solution of
"the last writeable directory when going up from the deleted file"... You said
it took a long time to find the trash directory when you did that. But I guess you
didn't mean when trashing a file, right? Going up should be quite fast.
I guess the problem is when listing trash:/, we have to find all trash dirs, and
due to removeable devices a global list doesn't solve the problem.
But maybe for removeable devices we can simply support the root-of-mountpoint
solution. 
Another solution for looking up trash dirs is a suid-root program that only writes, 
at the root of the partition, a dot file that lists the trash directories (per uid).
No out-of-disk-space issue anymore, and it makes the lookup fast.

This is getting a little bit complex but I don't see a good solution otherwise.

Let's summarize the possible solutions:

A) other partitions than $HOME not supported (implementations can either delete or move to ~/.Trash)

B) $topdir/.Trash
  B1) must be created by root (not obvious)
  B2) is automatically created by a suid-root program 
         (potential partition-filling exploit, unless sysadmin changes a config file, i.e. not obvious either)
  B3) B1 + we also support creating $topdir/.Trash as user, if $topdir is owned by user,
        and only allow that user to use that dir. 
        Useful for single-user systems with big mp3 or development partitions :)
  B4) B2 + same thing (supporting $topdir/.Trash as user)

C) $writeabledir/.Trash (where writeabledir is found by going up until finding a non-writeable dir)  
  (would still need a $uid subdir I guess, to avoid problems in group-writeable dirs)
  The creation of such dirs, and writing to them is easy; the problem is finding them.
  C1) config file in user's home dir listing known trash dirs. 
    Doesn't help with removeable devices, but I think we concluded trash dirs 
    on removeable devices is a bad idea anyway.
  C2) config file at root of partition. Either with suid-root program or only if user-writeable
    (which would already solve the problem with removeable devices)

Did I overlook anything?

The easiest to implement is A, then B1, then C1.
The one with most features is probably C2.
I'm fine with B3 and B4 too :)

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