A trash implementation MUST check if owner/group of the $topdir/.Trash is root?
dfaure at trolltech.com
Thu Jan 8 04:51:31 PST 2009
On Thursday 08 January 2009, Andrea Francia wrote:
> At the presente trash-cli does not check that the $uid mode and owner.
> What the trash implementation should do if the $uid is readable by others?
> Disabling the trashing operations?
Well I simply ignore that trash dir and trash to $HOME instead,
but some people don't like slower trash operations so I guess disabling
trashing is an option too. (It's just my opinion that it's better for the user
if it works, even if it's slower).
> What should the implementations do if the $uid is writable by others?
> Avoid to restore?
Same thing - if the security checks don't pass, we should just ignore
that directory IMHO.
> But I agree with you, the "security checks" could be written out
> more clearly
> in the spec so that all implementations check exactly the same things.
> Is there a bug tracker for the trash spec? This is not the first time
> that we talk about the improvements of the specs.
> If there is a bug tracker we could open an issue without the fear it is
Well the question is, who to assign the bugs to. Changes to the spec shouldn't
be decided by one maintainer, but rather after agreement between the three
parties involved in implementing it (which would be you, Alexander Larsson, and me).
So discussing things here is IMHO better than assigning bugs to one person.
David Faure, faure at kde.org, sponsored by Qt Software @ Nokia to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).
More information about the xdg