git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Junio C Hamano <gitster@pobox.com>
Date
Jan 6, 2015, 18:44 UTC
Message-ID
<xmqqlhlfpx57.fsf@gitster.dls.corp.google.com>
In-Reply-To
<xmqqd26sql0v.fsf@gitster.dls.corp.google.com>
Junio C Hamano <gitster@pobox.com> writes:
Show 44 quoted lines
> Jeff King <peff@peff.net> 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".

Previous: Paul SokolovskyNext: Jeff King
Message 12 of 14 in “git 2.2.x: Unexpected, overstrict file permissions after "git update-server-info"”
  1. Paul SokolovskyJan 5, 2015
  2. Torsten BögershausenJan 5, 2015
  3. Jeff KingJan 6, 2015
  4. 1/2 t1301: set umask in reflog sharedrepository=group testJeff King, Jan 6, 2015
  5. 2/2 update-server-info: create info/* with mode 0666Jeff King, Jan 6, 2015
  6. Junio C HamanoJan 6, 2015
  7. Jeff KingJan 6, 2015
  8. Junio C HamanoJan 6, 2015
  9. Jeff KingJan 6, 2015
  10. Junio C HamanoJan 6, 2015
  11. Paul SokolovskyJan 6, 2015
  12. Junio C HamanoJan 6, 2015
  13. Jeff KingJan 6, 2015
  14. Paul SokolovskyJan 6, 2015

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.