git server changes - how to allow https AND ssh now that /srv/git/xxx.git must be owned by http?
All, After recent git update, read only repos hosted on a local Apache server could no longer pull over https. (gitweb remained fine) Repositories closed read/write over ssh were fine. 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? Catch 22, unless /srv/git/xxx.git is http:http, https fails unless /srv/git/xxx.git is david:http, ssh fails Anybody else caught be this? The server is configured per https://wiki.archlinux.org/title/Git_server and the scm-git.com links. The "Note: Make sure that Apache can read and write to your repositories." seems incomplete. It's not just "read and write" it is "must own" for https and "can't own" for ssh? How to solve? -- David C. Rankin, J.D.,P.E.
On 24/06/16 03:41AM, David C. Rankin wrote:
All,
Hello everyone,
After recent git update, read only repos hosted on a local Apache server could no longer pull over https. (gitweb remained fine) Repositories closed read/write over ssh were fine.
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.
I think this is due to a change in git 2.45.1 that fixed a few security issues[0] and also made our internal workflows fail. The relevant change in devtools[1] contains a possible workaround, but this of course depends on whether you can treat the repositories as trusted or not. Cheers, chris [0]: https://raw.githubusercontent.com/git/git/master/Documentation/RelNotes/2.45... [1]: https://gitlab.archlinux.org/archlinux/devtools/-/commit/7cb72699f651a9e7ac8...
Op zo 16 jun. 2024 10:42 schreef David C. Rankin <drankinatty@gmail.com>:
[···] 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
On Sun, Jun 16, 2024, at 3:30 AM, Guus Snijders wrote:
Op zo 16 jun. 2024 10:42 schreef David C. Rankin <drankinatty@gmail.com>:
[···] 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.
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.
🤔 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 <drankinatty@gmail.com> 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.
On Sun, Jun 16, 2024, at 4:39 PM, 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.
You mentioned:
github does something. I can pull over https and ssh still works there.
I *highly* doubt GitHub uses standard Git in their backend at all. Your git repository is probably sitting in chunks somewhere in a highly distributed database with lots of indexing and whatnot added on top; you're not just connecting to a server and pulling the repo directly off disk somewhere. It may have started off using standard git, but I'll eat my hat if it still is. I had the "pleasure" of using/administering TFS (Microsoft Team Foundation Server) 8+ years ago when they introduced Git support; I spent a while trying to figure out where they stored the git repositories until I found that everything was in the database, just like everything else in TFS. They just implemented a git-compatible API of sorts where Git thinks it's talking to a regular git server.
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 Sun, 16 Jun 2024 03:41:57 -0500 "David C. Rankin" <drankinatty@gmail.com> wrote:
All,
After recent git update, read only repos hosted on a local Apache server could no longer pull over https. (gitweb remained fine) Repositories closed read/write over ssh were fine.
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?
Catch 22,
unless /srv/git/xxx.git is http:http, https fails
unless /srv/git/xxx.git is david:http, ssh fails
Anybody else caught be this?
The server is configured per https://wiki.archlinux.org/title/Git_server and the scm-git.com links.
The "Note: Make sure that Apache can read and write to your repositories." seems incomplete. It's not just "read and write" it is "must own" for https and "can't own" for ssh? How to solve?
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.
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 Tue, 18 Jun 2024 04:58:04 -0500 "David C. Rankin" <drankinatty@gmail.com> wrote:
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.
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.
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.
On Tue, 18 Jun 2024 15:42:10 -0500 "David C. Rankin" <drankinatty@gmail.com> 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?
If you are using SSH certificates then it depends; there is more than one way to organize them. E.g. if your certificates includes "principals" then the git user can be simply given an AuthorizedPrincipalsFile.
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 ...)
On 6/19/24 02:59, Łukasz Michalski wrote:
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
Now I'm confused, I already have gitweb browser configured for the repositories, and it continues to work just fine. It even uses AuthType Basic with AuthBasicProvider dbm. So kallithea will compliment what I already have and provided a way to handle the ownership mess from the command line. I'll go read, but that is new to me. Maybe I can get cli access for users to the git repos -- as a bonus :) -- David C. Rankin, J.D.,P.E.
participants (8)
-
Carl Lei
-
Christian Heusel
-
David C. Rankin
-
Guus Snijders
-
Ryan Petris
-
x choice
-
Óscar García Amor
-
Łukasz Michalski