On Sun, Jun 16, 2024, at 3:30 AM, Guus Snijders wrote:

Op zo 16 jun. 2024 10:42 schreef David C. Rankin :

...

[···] On the server the repositories under /srv/git were owned david:david (me). However, after the git change, git refused to serve over https unless the directories under /srv/git were owned by http.

Fine, change made - but now repos cloned read/write over ssh fail because the directory under /srv/git is no longer owned by me.

How do you make git repositories hosted on my local server allow clone/pull over https AND allow me to still close read/write over ssh? [...] unless /srv/git/xxx.git is http:http, https fails

unless /srv/git/xxx.git is david:http, ssh fails

Have you tried using http:david instead? And make sure the files are group-writable.

I haven't tested this, but this seems to answer all the mentioned constraints.

Mvg, Guus Snijders

You could try using something like bindfs (https://bindfs.org/) to bind mount /srv/git somewhere else with different permissions. Based on the man page it looks like you could do something like `bindfs --map http/git --map-group http/git /srv/git /srv/git-http`, then point apache to /srv/git-http instead of /srv/git.

🤔 maybe you can give yourself permissions to http owned files with ACLs https://www.redhat.com/sysadmin/linux-access-control-lists On Sun, Jun 16, 2024, 20:39 David C. Rankin wrote:

On 6/16/24 05:30, Guus Snijders wrote:

...

Have you tried using http:david instead? And make sure the files are group-writable.

I haven't tested this, but this seems to answer all the mentioned constraints.

Thank you Guus,

Unfortunately, yes, I've tried every combination of user:group ownership and it is really unfortunate that git won't server https unless the directories are 'owned' by http. I've even tried adding myself to the http group, but no luck.

Why I can't chmod 0775 repodir.git and then use david:http is indeed stange, but git requires http:dontcare to server https.

Of course ssh requires david:dontcare to server git over ssh.

I'll have to try Ryan's binfs work around and see if I can make something like that work. It's just wild that git doesn't have a published fix for this after the security change.

github does something. I can pull over https and ssh still works there. It may be worth opening an issue with git to see how they feel this catch 22 should be handled for locally hosted servers. If I find a fix, I'll report back.

-- David C. Rankin, J.D.,P.E.

El dom, 16-06-2024 a las 18:39 -0500, David C. Rankin escribió:

   github does something. I can pull over https and ssh still works there. It may be worth opening an issue with git to see how they feel this catch 22 should be handled for locally hosted servers. If I find a fix, I'll report back.

GitHub uses custom software to give you that functionality. My advice is to do the same. The best thing you can do (because it's the easiest) is to put a Forgejo[1] to take care of the repositories. You launch it with its own user and since the system will take care of https and ssh, both protocols should work without problems. Another option is to make it all belong to the http:http user/group by making sure that the ~/.ssh directory (of the http user, by default /srv/http/.ssh) and everything in it also belongs to that user and that the ~/.ssh/authorized_keys file has permissions 600 (and has your public key in it). Note that this forces you to move everything you have from /srv/git to /srv/http and that when accessing via ssh you will not do it with the git user (git@server:repo) but with the http user (http@server:repo). Greetings. [1]: https://forgejo.org/ -- Óscar García Amor | ogarcia at moire.org | http://ogarcia.me

On 6/17/24 00:03, Carl Lei wrote:

What about: create a dedicated "git" user, and run apache as user git? After all when new files are to be created they will have owner=running program, which could be a CGI program launched from apache, or a git program launched from SSH. If these are two different users it'll likely become a mess.

Thank your Carl, that is a thought, but one of last resort. I have a LOT of things served by Apache, eGroupware, Nextcloud, several custom authentication frontends to MariaDB and Postgres, and probably more I'm just not recalling at the moment. With the whole environment built about http:http as user/group, I'm going to exhaust efforts to keep the default Arch setup, otherwise that will add significant changes. I opened a thread on the git kernel mailing list at git@vger.kernel.org named: "Local git server can't serve https until repos owned by http, can't serve ssh unless repos owned by user after 2.45.1". They are aware of issues, just not sure where they could have come into the CVE backport process. We will see where it goes.... The whole "Dubious Ownership" approach to denying push/pull and even clone seems like an odd way tighten security. I'll pass along any solution I get so the information can be added teeeeeeeeo the https://wiki.archlinux.org/title/Git_server page. Thanks again. -- David C. Rankin, J.D.,P.E.

On 6/18/24 05:35, Carl Lei wrote:

Oh, I meant to run another apache instance, serving only the git CGI, and reverse-proxy from your main HTTP server to this dedicated git server. Actually it need not be apache, any kind of server capable of running CGI will do fine.

That I'll have to digest. Sounds like a good fix. For ssh, if everything is owned by a 'git' user, we would also need to have dedicated certificates for that user? I'll start reading about setting up a second instance and the proxy world. I'll also hope (strongly) the git kernel list discovers they have a few side-effects of fixing the CVEs in the latest version and publish a fix that makes it all transparent. (hope, but not plan on ...) -- David C. Rankin, J.D.,P.E.

Another lightweight alternative is to use kallithea (venv install) and put it behind apache. You will get web repo browser as a bonus :-) Regards, Łukasz On 18/06/2024 22.42, David C. Rankin wrote:

On 6/18/24 05:35, Carl Lei wrote:

...

Oh, I meant to run another apache instance, serving only the git CGI, and reverse-proxy from your main HTTP server to this dedicated git server.  Actually it need not be apache, any kind of server capable of running CGI will do fine.

That I'll have to digest. Sounds like a good fix. For ssh, if everything is owned by a 'git' user, we would also need to have dedicated certificates for that user?

I'll start reading about setting up a second instance and the proxy world. I'll also hope (strongly) the git kernel list discovers they have a few side-effects of fixing the CVEs in the latest version and publish a fix that makes it all transparent. (hope, but not plan on ...)