On Dec 10, 2006, at 10:30:00, Jakub Narebski wrote:
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.
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
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@xxxxxxxxxxx>
http://permalink.gmane.org/gmane.comp.version-control.git/29765
* Message-ID: <20061023051932.GA8625@xxxxxxxxxxxxxxxxxx>
http://marc.theaimsgroup.com/?
i=<20061023051932.GA8625@xxxxxxxxxxxxxxxxxx>
(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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html