[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 Aug 15, 2007, at 09:30:21, Lennart Sorensen wrote:
> On Wed, Aug 15, 2007 at 09:02:37AM -0400, Michael Tharp wrote:
>> 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.
> 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.

Going even further in this direction, the following POSIX ACL on the
directories will do what you want:

## Note: file owner and group are kmoffett

Basically any newly-created item in such a directory will get the
permissions described by the "default:" entries in the ACL, and
subdirectories will get a copy of said "default:" entries.

So yes, such functionality is nice; even more so because we already
have it. I think if you were really going to "extend" a UNIX
filesystem it would need to be in 2 directions:
(A) Handling disk failures by keeping multiple copies of
important files.
(B) Have version-control support
(C) Allowing distributed storage (also lazy synchronization and
offline modification support)

With some appropriate modifications and hooks, GIT actually comes
pretty close here. For larger files it needs to use a "list-of-4MB-
chunks" approach to minimize the computation overhead for committing
a randomly-modified file. The "index" of course would be directly
read and modified by vfs calls and via mapped memory. Merge handling
would need careful integration, preferably with allowing custom
default-merge-handlers per subtree. There would be lots more design
issues to work out, but it's something to think about

Kyle Moffett
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:57    [W:0.295 / U:0.556 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site