Trash mechanism

[Alexander Larsson]

On Fri, 2004-08-27 at 23:26, David Faure wrote:
> 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.

I can't think of any exploit atm if the setuid app properly doesn't
follow symlinks etc. I was just thinking there might be some way to
exploit it that we're not thinking of. Root permissions are always
dangerous.

I guess one problem is that it allows you to get a user-writable
directory on any filesystem on the system, even ones that users are not
meant to store data on. You can imagine for instance using it to create
a read-write directory on an ftp server, and then use that as a place
where people can trade warez.

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

Well, we used to do something else. It goes something like this:
1) The user is removing a file from a directory somewhere
2) If the user has permissions to remove a file, he also has permissions
to move it.
3) If the user has permissions to move a file in one directory on a
mounted filesystem, there exists at least one directory on it where he
has permissions to create a trash directory.
4) So, we do a breadth-first search from the topdir of the mountpoint
for a place where we can create a trash dir
5) When we find it, we save the location in a file in the users homedir,
so we can later find it faster (and it doesn't randomly change if
another directory becomes writable in the search path).

This system was disabled, because it was just to slow. My current
thinking is that the only way to get this working sanely is to do mtab
parsing for mountpoint toplevels and create/look for directories with a
fixed path relative to that. (The stat-up-the-tree approach we currently
do is problematic if there are symlinks, and requires you to keep track
of where you create trash-dirs.)

> 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 :)

In this case we should use .Trash-$uid, since several users could have
write permissions.

>   B4) B2 + same thing (supporting $topdir/.Trash as user)

.Trash-$uid here too.

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

We have such a file currently. One problem with it is that mountpoints
in it tend to be kept around, even if the filessystems/devices are
unmounted etc. This can cause it to become large, and full of things
like old NFS mounts. For large deployments this can become slow on
startup, as we need to stat all the mountpoints (I have reports of this
w/ Gnome).

> 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 :)

I'm most inclined towards B3 and perhaps B2. We need to better research
the security implications of B2.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl at redhat.com    alla at lysator.liu.se 
He's a witless umbrella-wielding cop who dotes on his loving old ma. She's a 
chain-smoking tempestuous schoolgirl with the power to bend men's minds. They 
fight crime!