On 7/27/24 10:46 PM, Jamie Landeg-Jones wrote:
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.
--
David C. Rankin, J.D.,P.E.
