Re: Using GIT to store /etc (Or: How to make GIT store all file permission bits)

From: Kyle Moffett <mrmacman_g4@mac.com>
Date: Dec 10, 2006, 18:10 UTC
Message-ID: <A52817B6-0265-4164-8E5D-334AF92DC267@mac.com>
In-Reply-To: <elh91b$v6r$1@sea.gmane.org>

On Dec 10, 2006, at 10:30:00, Jakub Narebski wrote:

Show 7 quoted lines

> 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.

Show 8 quoted lines

>> 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?

> 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

Show 10 quoted lines

> 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