From: "W. Michael Petullo" <mike@flyn.org>
To: Jeff King <peff@peff.net>
Cc: git@vger.kernel.org
Subject: Re: Git clone reads safe.directory differently?
Date: Sun, 28 Jul 2024 10:27:00 -0500 [thread overview]
Message-ID: <ZqZjRMqpEV_3WIkD@imp.flyn.org> (raw)
In-Reply-To: <20240727215845.GA1263246@coredump.intra.peff.net>
>> Glen Choo's commit 6061601d modified Git so that safe.directory could
>> be set on the command line using "-c". It seems most sub-commands work
>> this way, but not "clone". Here is an example:
>
> This is because upload-pack, the server half of a fetch/clone, is run as
> a separate process which does not accept the client-side "-c" options.
> See this email for more details and a workaround:
>
> https://lore.kernel.org/git/20240529102307.GF1098944@coredump.intra.peff.net/
Thank you, Jeff! This works and makes sense, although I can see how users
would be confused by the edge case.
For completeness, I investigated how to do the same over SSH. Imagine a
repository user-owned by Bob, but group-owned with r/w/x permissions by
a group containing Alice. It seems the same trick fails because git-shell
rejects the custom upload-pack command:
git -c safe.directory="*" clone -u 'git -c safe.directory="*" upload-pack' alice@git.example.com:/shared/repository
Cloning into 'git'...
fatal: unrecognized command 'git -c safe.directory="*" upload-pack '/shared/repository''
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
I was able to overcome this by creating /home/alice/git-shell-commands/upload-pack-safe,
placing the following there
#!/bin/sh
git -c safe.directory="$1" upload-pack $1
and running:
git -c safe.directory="*" clone -u upload-pack-safe alice@git.example.com:/shared/repository
This seems to be another interface edge case. Is my solution reasonable,
or is there something else that would be more consistent?
Related: Would anyone be interested in working on an academic paper
about safe.directory? It seems like people who write Git forge-type
software or other collaborative systems based on Git would benefit from
a rigorous description of the conditions and operations under which the
use of safe.directory is indeed safe. I am not sure I have this worked
out in my own mind yet. Something like "Setuid Demystified" from USENIX
2002 might help.
--
Mike
:wq
next prev parent reply other threads:[~2024-07-28 15:27 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-27 16:14 Git clone reads safe.directory differently? W. Michael Petullo
2024-07-27 21:58 ` Jeff King
2024-07-28 15:27 ` W. Michael Petullo [this message]
2024-07-28 22:48 ` Jeff King
2024-07-30 11:37 ` W. Michael Petullo
2024-07-30 22:28 ` brian m. carlson
2024-07-30 22:49 ` Junio C Hamano
2024-07-30 22:55 ` Junio C Hamano
2024-07-30 23:05 ` brian m. carlson
2024-07-31 7:28 ` Jeff King
2024-07-31 16:23 ` Junio C Hamano
2024-07-31 22:08 ` Junio C Hamano
2024-08-01 6:14 ` Jeff King
2024-08-01 14:59 ` Junio C Hamano
2024-08-01 21:26 ` brian m. carlson
2024-08-01 21:52 ` Junio C Hamano
2024-08-05 9:47 ` Jeff King
2024-08-05 15:34 ` W. Michael Petullo
2024-08-05 15:49 ` Junio C Hamano
2024-08-01 6:08 ` Jeff King
2024-07-31 7:19 ` Jeff King
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZqZjRMqpEV_3WIkD@imp.flyn.org \
--to=mike@flyn.org \
--cc=git@vger.kernel.org \
--cc=peff@peff.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.