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

[Junio C Hamano <gitster@pobox.com>]

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