Subject: Re: git 2.2.x: Unexpected, overstrict file permissions after "git update-server-info"

From: Junio C Hamano <[email-masked]>
Date: Tue, 06 Jan 2015 10:44:04 -0800

Junio C Hamano <[email-masked]> writes:

> Jeff King <[email-masked]> writes:
>
>> Yeah, I didn't consider the mode impact of using mkstemp. That is
>> definitely a regression that should be fixed. Though of course if you
>> really do want 0644, you should set your umask to 0022. :)
>> ...
>> If you haven't set core.sharedrepository, then adjust_shared_perm is a
>> noop. But you shouldn't have to do that. Git should just respect your
>> umask in this case.
>
> Thanks for a nicely done patch series, but I am not sure if I agree
> with the analysis and its conclusion.
>
> If adjust_shared_perm is a no-op, how do we ensure that other files
> that need to be served by a dumb HTTP server are readable by it?  Is
> it because we just happen not to use mkstemp() to create them (and
> also is it because the pushers do not have umask 007 or stronger to
> prevent files from being read by the HTTP server user)?
>
> Is our goal here to give the users this statement?
>
>     For shared repository served by dumb HTTP and written by users
>     who are different from the user that runs the HTTP server, you
>     need to do nothing special.
>
> If that is the case, shouldn't the rule be something a lot looser
> than "we should just respect your umask"?  To satisify the above
> goal, shouldn't we somehow make it readable by the HTTP user even
> when some pusher has a draconian 0077 umask?  But that, while still
> complying to the promise of "nothing special", would imply we would
> have to make everything readable everywhere, whish is an unachievable
> goal.  We need to somehow be able to say "this repository should be
> readable by these people" per-repository basis.
>
> And we have a mechanism exactly designed to do so to defeat
> draconian umask individual users have.
>
> It feels to me that the old set-up were "working" by accident, not
> by design (I may be mistaken--so correct me if that were the case).
> And if that is the case, I do not think it is a good idea to try to
> hide the broken configuration under the rug longer.  "As long as
> everybody writes world-readable files, you do not have to do
> anything" will break when the next person with 0xx7 umask setting
> pushes, no?

Having said all that, I agree that the patch series does the right
thing in that it stops us from tightening without being told.  It's
just that the change is not a general solution for "you shouldn't
have to set core.sharedrepository even when people with different
umask settings push into the same repo".