Re: Thinking outside the box on file systems

From: Kyle Moffett
Date: Wed Aug 15 2007 - 09:54:23 EST


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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/