On Wed, Aug 15, 2007 at 09:02:37AM -0400, Michael Tharp wrote: > 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 :)
Posix ACLs seem to solve most group permissions issues and control of permission propegation. It actually works quite well on Linux. I am surprised if there aren't lots of people already using it. Remember that existing software expects a unix style interface, since they are unix programs. Anything you invent MUST be compatible with the standard unix view of things, even if it offers additional options. -- Len Sorensen - 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/