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
u::rw-
g::rw-
u:lsorens:rw-
u:mtharp:rw-
u:mperkel:rw-
g:randomcvsdudes:r-
default:u::rw-
default:g::rw-
default:u:lsorens
default:u:mtharp:rw-
default:u:mperkel:rw-
default:g:randomcvsdudes:r-
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
Cheers,
Kyle Moffett
-
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/
