[Fwd: Re: shared trash directories in the trash spec]
Brian J. Tarricone
bjt23 at cornell.edu
Thu Feb 7 10:11:10 PST 2008
Alexander Larsson wrote:
> On Wed, 2008-02-06 at 10:29 -0800, Brian J. Tarricone wrote:
>>> 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.)
> There is really no easy, portable, and reliable way to check if a device
> is removable or not.
True, I suppose I was thinking more of the Linux/HAL case.
>> 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:
> Its your opinion that they should be mounted by the logged in user.
> However this is not how distros like Ubuntu and Debian do this, so your
> opinion is not the only thing we need to take into consideration.
Ok, so maybe they aren't mounted by the logged-in user, but presumably
the logged-in user has write permissions to the partition (if not,
whether or not we support trashing to it is moot). If the partition is
mounted in such a way that restricts access to just the logged-in user,
more the better. If not, malicious users will be able to mess with the
user's non-trashed files as well as trashed files.
>> 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.
> I think for instance on any Ubuntu system with a windows partition all
> users in the "hotplug" group will have read/write access it. Even if you
> don't think this is sane its a reality that we have to handle.
But again, what's the percentage of these that are going to be
multi-user systems and not just someone at home who is trying out Ubuntu
(for example) and can't give up their Windows partition yet? Dual-boot
lab computers might fall into this category, but, again, how can it be
expected that *any* files on such a partition are "safe" for the
logged-in user if other users can modify them? If we can't, does
allowing a shared trash actually decrease security? My opinion is no,
it doesn't. A malicious user could replace another user's trashed file
with something that does something bad, but they could do the same with
a non-trashed file, which sounds like it would be more attractive to me
from an attacker's point of view.
>>> 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.
> Have you actually read the trash specification? It doesn't seem like you
> know what the current implementation would do in the FAT case if we just
> allow the normal behaviour (ignoring setuid and uids). If the sysadmin
> has created a .Trash directory then the trash will be put
> in .Trash/$uid/, otherwise in .Trash-$uid. Neither of these are shared
> trash directories, even if the permissions make them readable and
> writable by anyone. This is not ideal at all for a FAT filesystem where
> we want a shared trash dir.
Sorry, I was getting a bit confused (yes, I have read the trash spec,
but it's been a while). I was more objecting to the need for 'the
sysadmin' (which in many [most?] cases will be 'the end-user') to have
to take an extra step to make trashing work.
Ignoring permissions for a moment, if a FAT partition is mounted, what's
wrong with still creating .Trash-$uid? Sure, there's no actual
protection that prohibits a malicious user from replacing a file in
someone else's trash, but that's the same as if there's a shared trash.
At least with separate unprotected trashes, in a world where users
with access all 'play nice', each user still only sees their own trashed
Removable drives again become a problem since users may not have the
same UID on multiple systems. But this isn't a problem inherent to
FAT/NFTS volumes (though I'd imagine you'd only format a removable
device as ext3 if you were only going to use it in unix-like machines
where your UID is the same on every machine). But it would still be
very disconcerting to see some trashed files appear on one machine, and
other trashed files appear on another.
So sure, I can see now why you'd want to use something like
.Trash-shared, then. But please don't put into the spec a requirement
to make a sysadmin (end-user!) enable this manually, regardless of
whether or not it requires creating the folder manually, or a knob in a
prefs panel somewhere. Trashing should just work. I suppose for people
who are extra security-conscious, it would be cool to have an option to
"disable trash on removable devices" -- but that should be up to the
implementation, and of course relies on the implementation to also know
how to figure out if a drive is removable or not.
More information about the xdg