Trash spec (relative paths; security checks)
dfaure at trolltech.com
Fri Sep 10 22:11:54 EEST 2004
> 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).
More information about the xdg