Jeff King <peff@xxxxxxxx> 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?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html