On Dec 10, 2006, at 10:30:00, Jakub Narebski wrote:
quoted text
> Jeff Garzik wrote:
>> I actively use git to version, store and distribute an exim mail  
>> configuration across six servers.  So far my solution has been a  
>> 'fix perms' script, or using the file perm checking capabilities  
>> of cfengine.
>
> Fix perms' script used on a checkout hook is a best idea I think.

Hmm, unfortunately that has problems with security-related race  
conditions when used directly for /etc.  Think about what happens  
with "/etc/shadow" in that case, for example.  (/etc/.git is of  
course 0700)  I'm sure there are others where non-root daemons get  
unhappy when they get an inotify event and their config files have  
suddenly become root:root:0600.  I also want to be able to "cd /etc  
&& git status" to see what changed after running "apt-get update" or  
maybe fiddling in SWAT or webmin, so a makefile which installs into / 
etc won't quite solve it either.  It would also be nice to see when  
things change the permissions on files in /etc, or even bind-mount an  
append-only volume over /etc/.git/objects to provide additional data  
security.

quoted text
>> But it would be a lot better if git natively cared about ownership  
>> and  permissions (presumably via an option).
>
> There is currently no place for ownership and extended attributes  
> in the tree object; and even full POSIX permissions might be  
> challenge because for example currently unused 'is socket'  
> permission bit is used for experimental commit-in-tree submodule  
> support.

What about doing something crazy like "is socket" && "is directory"  
&& "is symlink"?  Or something else that old GIT versions would  
ignore and new GIT versions could do something useful with?  Perhaps  
like I mentioned in an earlier email, the new data could be stored as  
part of a modified "file" object.  Alternatively could a directory  
have a file named with an empty string with bogus mode bits which  
points to an extended-attributes-tree object?

quoted text
> And given Linus stance that git is "content tracker"...

Extended attributes are content too!  This includes things like  
icons, security labels (Think unclassified/confidential/secret/top- 
secret/etc), ACLs, summaries, and other metadata.  Content tracker  
purists could also just ignore the new default-off config options and  
be perfectly happy with status-quo. :-D

quoted text
> In the loooong thread "VCS comparison table" there was some talk  
> about using git (or any SCM) to manage /etc. Check out:
>
>  * Message-ID: <Pine.LNX.4.64.0610220926170.3962@g5.osdl.org>
>    http://permalink.gmane.org/gmane.comp.version-control.git/29765
>  * Message-ID: <20061023051932.GA8625@evofed.localdomain>
>    http://marc.theaimsgroup.com/? 
> i=<20061023051932.GA8625@evofed.localdomain>
>
> (and other messages in this subthread).

I have, and while it's interesting material that thread produced no  
real patches :-D.  I'd like to introduce some new config options to  
control the new code: "preserve_full_perms", "preserve_posix_acls",  
"preserve_security_labels", and "preserve_user_xattrs" which default  
to false but when set modify GIT's behavior to store, retrieve, and  
compare additional data.

If you have any suggestions on how to store the data such that old  
GIT ignores it I'm all ears :-D.

Cheers,
Kyle Moffett

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html