Trash mechanism

[C. Gatzemeier]

> > /group  root:root rwxr-x--
> > /group/student staff:student  rwxrws---
> > /group/teacher root:teacher rwxrws---
> >
> > /group/.Trash root:root rwxr-x---
> > /group/.Trash/student staff:student  rwxrws---
> > /group/.Trash/teacher root:teacher  rwxrws---
> > /group/.Trash/teacher/classlist[deldate] smith:teacher rw-rw----
>
> Plus /group/.Trash/smith/* for files where smith removed the
> group-writeable flag before deleting the file.

Why shouldn't it just end up
/group/.Trash/teacher/classlist[deldate] smith:teacher rw-r----- ?


> But this still leads to some sort of "privilege escalation":
> Imagine I store group-writable files in a non-group-writable directory
> (because I used chmod g-rwx on the directory, but I can't change my umask,
> so every new file is still g+w). When I trash such a file, it would
> suddenly become visible to the whole group again.

Only if it is pooled together with other files into one directory. If it's 
kept under a replica of the non-group-writable directory and all the rest of 
the directories relative to $topdir the permissions can be exacltly the same.


> This is assuming that we
> choose between groups/ and users/ depending on the g+w flag.

I see, are you thinking of /groups and /users as subdirectories to contain 
trashes from different people/groups?

What I rather meant was having only one trash directory (the $topdir/Trash) 
that will reassembles the tree and permissions of the original tree 
wherever /Trash resides.
If you trash one file from the "students" group directory it will end up as a 
file in the students group directory under /Trash. If it is the first file 
deleted from the studens group directory it will be the only one in there.

This is what I meant by not pooling the files together where the file would 
end up in the /files directory. Basicly "detatch" subtrees from the original 
location and then instead of "attatching" them all to one place (like /files) 
reassemble them to one tree under /Trash so that all files are under the same 
permission hierarchie as they where before trashing them.


> There's basically no way to know if the user who deletes the file wants to
> make it available to the group (yes, it was initially, but maybe the user
> trashes the file _because_ it was there by mistake and shouldn't be read by
> the group :-)

Ok, it's probably a close call ;-) We really don't know I guess. My take would 
be not to imply a permission change when trashing. Let the user use delete to 
correct his error (let's not assume we are smarter than her/him).

Christian