shared trash directories in the trash spec
Alexander Larsson
alexl at redhat.com
Wed Feb 6 03:34:17 PST 2008
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.
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. 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.
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.
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.
Opinions?
More information about the xdg
mailing list