shared trash directories in the trash spec

[Brian J. Tarricone]

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.

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

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:

1a.  The device is owned and only used by one person.

1b.  The device is used by multiple people, but there are no protections
on the volume to ensure that people don't read each others files anyway,
so it's moot.

For case #2, it's a little more complicated, but not by much.  I don't
see why all this added complexity is necessary.  Anyone who has read
access to a FAT/NTFS volume can read the entire volume.  There should be
no expectation of "privacy" anyway when working with this kind of
volume, regardless of being able to trash files or not.

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

Then this should be changed to allow trash folders on volumes that won't
accept a 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.

... and then this is not a problem anymore.

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

And everyone with access to the mount can read each other's regular
non-trashed files too.

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

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.

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

If you have a FAT filesystem, period, it will basically act as a shared
filesystem between all users.  Trash is not special in this regard.

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

There we go.  Exactly.  So what's the big deal?

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

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.

Putting the burden on the user to know about the implementation details
of the trash spec is a bit silly, no?  Even if that knowledge is only "I
need to do something special in my GUI to make trashing work on new USB
drives I plug in" -- that's too much.  This should Just Work.  Adding an
option for this is just an "unbreak my software, please" option.

As you yourself note, any user with write access to the volume can
enable this, so there's no point in adding complexity here to try and
solve a security problem that IMHO a) can't be solved while maintaining
functionality, and b) doesn't really exist, or at least is not specific
to or relevant to the trash spec.

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

Disagree.  The trash implementation should fall back to shared trashing
(whatever the implementation ends up looking like) if it cannot do
trashing in the 'normal' way.  Not doing so will only lead to confusion
and unnecessary complication.

	-brian