alan wrote: > Imagine the fun you will have trying to write a file name and being told > you cannot write it for some unknown reason. Unbeknownst to you, there > is a file there, but it is not owned by you, thus invisible.
This jumped out at me right away. In such a system, an attacker with write permissions on a "sticky" directory like /tmp could probe for others' files by attempting to create them and recording all cases where permission was denied due to an existing, hidden file. But of course, this was just an example of something a less UNIX-y permission scheme could do, not a key part of such a design. Personally, what I'd like to see is a better way of dealing with propagation of ownership. Currently, in order to allow "collaboration" directories where a directory tree is owned by a certain group and anyone in that group can write and create files, one has to change the system umask, use a magical bit on the collaboration directory to propagate group ownership, and create a group for every user on the system in order to keep their personal files safe with the new umask. This seems highly flawed. I suggest that propagation of group ownership should be the default mode, not a special one, and that the group-writable permissions should also be propagated to new files and directories. This way, the user's home directory would remain 0755, while the collaboration directory could be 0775, without any changing of umasks. Of course, this would go against tradition, and cause some mayhem in the logic responsible for magically determining permissions for new files, but since we're talking about thinking outside of the box, I think that's excusable :) -- m. tharp - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/