c.gatzemeier at tu-bs.de
Sun Aug 29 23:40:10 EEST 2004
> > /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).
More information about the xdg