[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kfm-devel
Subject:    Re: Konqueror delete unification
From:       Jos van den Oever <kdelists () vandenoever ! info>
Date:       2003-07-18 5:53:16
[Download RAW message or body]

On Thursday 17 July 2003 23:13, Koos Vriezen wrote:
> Not uncommon though, like tar. Yes -i like cp/mv, so only for restoring.
Well, tastes differ :-)

> > - put mktrash and trashfind in the daemon: the user nor root should need
> > to run them
>
> Not sure if a daemon is necessary, but 'mktrash -a' (make all trash dirs
> if not there yet) is probably useful. Why do you think of a daemon (note
> that 'trash' is suid)?

You're right. No daemon is needed if trash is suid. The 'untrash' 
functionality also needs to be suid if there is a central list of trash 
files. Is it wise to have a suid program write to disk? Sounds like a 
security problem. On could e.g. override ones quota.

> > Actually the Trash Can project looks pretty well thought out. trash://
> > can probably build straight on top of it. Too bad it's not in
> > Knoppix/Debian, otherwise I'd immediately apt-get it. I think I'll
> > install it anyway.
>
> Only to user oriented imo, and no multible trash dirs.
Hmm, user trash dirs are a security requirement, IMHO: other users must not be 
able to see which files another user has deleted.

> (One thing I thought of afterward, is the permission of the trashed file.
>  It should be the most restrictive when going up the directory tree, eg. a
>  644 in ones home dir, with permission 701, should be 600 I think.)

If the trashdir has permission 700, then the permissions of the files inside 
do not matter. They can be kept unchanged.

[prev in list] [next in list] [prev in thread] [next in thread]