Trash spec (relative paths; security checks)

[David Faure]

> A relative pathname is to be from the directory in which the trash directory 
> resides (i.e., from $XDG_DATA_HOME for the “home trash” directory); 
It doesn't make much sense to have relative paths from XDG_DATA_HOME,
which is by default ~/.local/share - who deletes files from under there?
I think the example should be changed into
"(i.e. from $topdir for a trash on a mounted resource)"

This clears up the question "what's the directory in which $topdir/.Trash/$uid resides?"
"$topdir or $topdir/.Trash"?
I think we obviously want $topdir to be the base for the relative paths.

> it MUST not contain “..”, and for files not “under” that directory, absolute
> pathnames must be used. The system SHOULD only support absolute 
> pathnames in the “home trash” directory, not in the directories under $topdir.     

Yes - which is why the example for a relative pathname should be about $topdir :)

PS: in terms of security checks, the spec has info on the required permission and ownership
for .Trash/, but I suppose it should also make clear that the $uid subdir or the .Trash-$uid directory,
if it exists already, should be owned by the current user, shouldn't be a dir, not a symlink,
should be at least 0700 - and maybe we need restrictions on 'group' and 'other' permissions?
When creating my own trash I use 0700, but the question here is what should we check for,
when finding an existing trash directory.

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).