[lkml]   [2007]   [Aug]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Thinking outside the box on file systems
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
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2007-08-15 15:51    [W:0.096 / U:4.064 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site