Re: [RFC] Plumbing-only support for storing object metadata

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 16, 2008, 09:55 UTC
Message-ID: <7vd4k9e120.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <20080816062130.GA4554@oh.minilop.net>

Josh Triplett <josh@freedesktop.org>, Jamey Sharp <jamey@minilop.net> writes:

> This hook would need to provide a way to process these updates before
> the blob or tree contents get put into place.  For example, if you check
> out /etc/shadow, you need to apply the non-world-readable permissions
> *before* you write out the contents.

I think such atomicity or "checkout race problem" is irrelevant.

I'd like to make a comment on this point, even though at the moment (especially before the real release), I am not very interested in where this "proposal" is going.

You mention that you would resolve attribute conflicts just the same way you would resolve contents conflicts, which in turn means that you would check out a half-merged state with conflict markers to the working tree, fix up the filesystem entity (both contents and presumably its attributes like perm bits, ownership, xa and whatnot), and mark the path resolved. Even without talking about attributes conflicts, what's your position on the time-window during which the contents of /etc/shadow and /etc/password have conflict markers in them?

Luckily, the markers do not have sufficient number of colons, and that would protect your system from attempts to break into it with a phoney username '=======' with an empty password ;-), but I think you get the idea. Anything that has to be in some consistent state that cannot see conflicted state in the middle should not be merged in-place [*1*], [*2*].

So please simplify your requirements and at least drop atomicity argument.

I am _not_ fundamentally opposed to somebody who wants to use git or any other SCM as a cooler representation of snapshots than a sequence of tarballs. I however would be unhappy if your design and implementation becomes more complicated than otherwise only because you try to deal with the atomicity issue. IOW, if your solution would become much simpler once you pare down the atomicity requirement, then I'd reject the more complex variant with atomicity in any second, even though I might still find the simpler variant that does not care about atomicity worth considering.

[Footnotes]

*1* That is why people often frown upon "using SCM to track changes of a live system in-place", and suggest tracking source material in SCM, and build material to deploy from the source and install into the final destination (not limited to /etc but more often so for e.g. web server assets) as a better practice.

*2* Also you should realize your "/etc/shadow must be non-world-readable from the beginning" is a very application specific wish. What if the attribute you are trying to enforce is "this path must always be world-readable"? Are you going to limit this "attribute enhancements" to what you can specify at creat(2) time only? How would you handle "this path must be owned by user 'www-data' (assuming root drives git)", which would be done by creat(2) followed by chown(2)?