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 _______________________________________________ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg