shared trash directories in the trash spec

[David Faure]

On Wednesday 06 February 2008, Alexander Larsson wrote:
> There are some issues with using the trash spec on FAT and NTFS systems.
> These filesystems don't support storing UIDs, nor does it support the
> sticky bit. Instead, the way they are generally mounted in a writable
> way under unix is:
> 
> a) All files are owned by the user mounting the filesystem
> b) All files are owned by root, and a group that all desktop users are
> in
> 
> For neighter of these cases the sysadmin-created .Trash directory will
> work, as we can't store the setuid bit. In case b, even the
> per-user .Trash-$uid directory will fail, because the automatically
> created directory will not be owned by $uid. In case a the .Trash-$uid
> creation will succeed, but the data in there is visible to anyone with
> read rights to the filesystem.
> 
> 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.

Right.

> The trash spec says this:
>  
>         If this directory is present, the implementation MUST, by
>         default, check for the “sticky bit”. (It MAY provide a way for
>         the administrator, and only the administrator, to disable this
>         checking for a particular top directory, in order to support
>         file systems that do not have the “sticky bit”).
>         
> However, this has a few problems. First of all its kinda tricky to
> specify options like this on a per-mount basis, since the mount could be
> mounted on different places each time, etc. 

Yes (I never implemented this admin-configuration stuff).

> But even worse, if you 
> allowed the non-sticky bit version then everyone with access to the
> mount could read each others trash directories, and even put things in
> other peoples trash directory. The later is a mild security issue,
> because that file would show up in the trash:// dir for the user with no
> information about where it came from.
> 
> In fact, If you allow any kind of trash at all on a FAT filesystem it
> will basically act as a shared trash betweeen all users. Furthermore,
> all files that could be trashed on the filesystem can already be seen by
> everyone, so using a shared trash dir does not really cause any privacy
> or security issues beyound the initial ones. So, it makes some sense to
> actually use this as the implementation. In fact, FAT is often used on
> removable media that is moved between users and machines, and in that
> case you really want to see the files trashed on another machine rather
> than having a lot of data being uses in a hidden trash directory for
> another user, so in this case this is very useful.

Yes.

> Here is a proposal of how this could work:
> 
> If .Trash/shared exists, and both .Trash and shared are owned by root or
> the current user (no need for .Trash to be setuid), and you are allowed
> to write in the shared directory (check with "access(path, W_OK)") then
> use this directory as the trash directory for the mount. This directory
> should not be created automatically.

I disagree with the "should not", and you do too, cf below.

> For normal unix filesystem there is no real risk from this. Its not
> normally gonna be enabled by the sysadmin, and since we do the uid check
> for the shared directory other users cannot create it even in a
> sticky-bit .Trash dir (in order to expose other peoples trashed files).
> 
> 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.
> 
> We don't recommend that the file trashing implementation creates the
> shared trash directory, as that can be somewhat surprising on multiuser
> systems for regular FAT partitions. However, a desktop implementation
> could for instance (based on a config option) create the shared trash
> dir when it detects a removable media with a FAT filesystem, as using a
> shared trash dir on that is generally very useful.

Yep, that sounds good. Better than the sysadmin or the [very-knowledgeable user]
having to create .Trash/shared by hand...

Andrea, would this also solve your problem?

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