[Fwd: Re: shared trash directories in the trash spec]

[Brian J. Tarricone]

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

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.

	-brian