All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.