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, [EMAIL PROTECTED], sponsored by Trolltech to work on KDE, Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org). _______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
