Re: Thinking outside the box on file systems

[Kyle Moffett <mrmacman_g4@mac.com>]

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