Show 11 quoted lines
> From what I gather, the idea was to stop a client user from unintentionally
> running potential hook scripts that could be evil. A similar protection was
> already present, I note, for other methods (I couldn't run git log and other
> commands directly on a repo i had unix-level read access to, but were owned
> by another user until I added the safe directory thing in .gitconfig)
>
> Closing this hole to make security more consistent is fair enough... however,
> in the case of git-http-backend the "safe directory" method doesn't work at
> all!
>
> Is this an accurate summary of the situation?
Yes it is.
Prior to the change, the repositories on my git server were owned by the
user with push privileges and all repositories would still be cloned over
https. Now unless the files are owned by http (what the web server runs as on
Archlinux), https users cannot update their repositories anymore. Changes
pushed to the server by the user with ssh access (and owner of the files)
cannot be pulled over https.
On the other side of the issue, if I make the webserver the owner of the
repos, the ssh user cannot push or pull.
Gitweb remains happy no matter the ownership.
I'm all for more security and welcome it, but you have to provide a way to
configure it so that prior functionality is simply not broken. I'll have to
search and find the little truth-table style of repo user:group ownership and
the resulting succeed:fail with push/pull from the server.
I'd be happy if the docs were just updated with a concise explanation of
how to support both ssh and https to the same repo running under Apache -- if
that is doable. It must be, github does it. I haven't had the time I'd like to
to further investigate. Next month looks better.