[Fwd: Re: shared trash directories in the trash spec]

[Alexander Larsson]

Seems i didn't send this reply to the list.

-------- Forwarded Message --------
From: Alexander Larsson <alexl at redhat.com>
To: Brian J. Tarricone <bjt23 at cornell.edu>
Subject: Re: shared trash directories in the trash spec
Date: Thu, 07 Feb 2008 10:02:32 +0100

On Wed, 2008-02-06 at 10:29 -0800, Brian J. Tarricone wrote:

> > This is all pretty bad, and the current solution to this in both KDE4
> > and gnome (gio) is that trash to FAT/NTFS partitions is not allowed.
> 
> Why is this a big deal?  For FAT/NTFS partitions we can assume one of 
> the following:
> 
> 1.  The partition is on a removable drive that 'belongs' to the 
> currently-logged-in user.  (No need to assume this; can check if the 
> device is removable or not.)

There is really no easy, portable, and reliable way to check if a device
is removable or not.

> 2.  The partition is a "foreign" partition on a fixed drive in the 
> system (e.g. a Windows partition) that *someone* has mounted.
> 
> For case #1, the solution is simple: the volume should be mounted owned 
> by the logged-in user, and only the logged-in user should be able to 
> trash files.  There's no reason for these types of devices to have 
> per-user trashes anyway, because:

Its your opinion that they should be mounted by the logged in user.
However this is not how distros like Ubuntu and Debian do this, so your
opinion is not the only thing we need to take into consideration.

> Very mild, IMHO.  My expectation is that people on multi-user systems 
> won't run into this, because they won't have persistently-mounted 
> world-readable/writable volumes that don't support unix permissions. 
> Removable devices should be mounted with r/w access ONLY for the user 
> who plugged it in (or possibly the user at the console, which may
> change while the device is plugged in).  I think it's reasonable to
> expect this in a sanely set-up system.

I think for instance on any Ubuntu system with a windows partition all
users in the "hotplug" group will have read/write access it. Even if you
don't think this is sane its a reality that we have to handle.

> > However, this allows sysadmins or users to create the .Trash/shared
> > directory to enable some form of trashing on FAT filesystems. The only
> > drawback is that anyone that has write access to the filesystem can
> > enable this, which may lead to problems. For instance, on a multiuser
> > system one user could enable this and then another user trashes a file,
> > and then the first user empties the trash. However, there are no real
> > security issues as both the first and the second user could access all
> > files on the mount anyway.
> 
> Why is this necessary?  Just use the existing .Trash/ dir, and change 
> the spec so the stronger security requirements are are applied to 
> filesystems that support unix permissions, and the weaker shared mode is 
> used for filesystems that do not.

Have you actually read the trash specification? It doesn't seem like you
know what the current implementation would do in the FAT case if we just
allow the normal behaviour (ignoring setuid and uids). If the sysadmin
has created a .Trash directory then the trash will be put
in .Trash/$uid/, otherwise in .Trash-$uid. Neither of these are shared
trash directories, even if the permissions make them readable and
writable by anyone. This is not ideal at all for a FAT filesystem where
we want a shared trash dir.