From: Junio C Hamano <gitster@pobox•com>
To: Jeff King <peff@peff•net>
Cc: Paul Sokolovsky <paul.sokolovsky@linaro•org>, git@vger•kernel.org
Subject: Re: git 2.2.x: Unexpected, overstrict file permissions after "git update-server-info"
Date: Tue, 06 Jan 2015 10:44:04 -0800 [thread overview]
Message-ID: <xmqqlhlfpx57.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <xmqqd26sql0v.fsf@gitster.dls.corp.google.com> (Junio C. Hamano's message of "Tue, 06 Jan 2015 02:08:16 -0800")
Junio C Hamano <gitster@pobox•com> writes:
> 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".
next prev parent reply other threads:[~2015-01-06 18:44 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-05 19:07 git 2.2.x: Unexpected, overstrict file permissions after "git update-server-info" Paul Sokolovsky
2015-01-05 22:23 ` Torsten Bögershausen
2015-01-06 3:47 ` Jeff King
2015-01-06 3:49 ` [PATCH 1/2] t1301: set umask in reflog sharedrepository=group test Jeff King
2015-01-06 3:50 ` [PATCH 2/2] update-server-info: create info/* with mode 0666 Jeff King
2015-01-06 18:47 ` Junio C Hamano
2015-01-06 19:39 ` Jeff King
2015-01-06 21:43 ` Junio C Hamano
2015-01-06 21:47 ` Jeff King
2015-01-06 10:08 ` git 2.2.x: Unexpected, overstrict file permissions after "git update-server-info" Junio C Hamano
2015-01-06 12:43 ` Paul Sokolovsky
2015-01-06 18:44 ` Junio C Hamano [this message]
2015-01-06 19:37 ` Jeff King
2015-01-06 12:12 ` Paul Sokolovsky
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqlhlfpx57.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=paul.sokolovsky@linaro$(echo .)org \
--cc=peff@peff$(echo .)net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox