git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Git clone reads safe.directory differently?

From
WPW. Michael Petullo <mike@flyn.org>
Date
Jul 28, 2024, 15:27 UTC
Message-ID
<ZqZjRMqpEV_3WIkD@imp.flyn.org>
In-Reply-To
<20240727215845.GA1263246@coredump.intra.peff.net>
Show 9 quoted lines
>> 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
Previous: Jeff KingNext: Jeff King
Message 3 of 21 in “Git clone reads safe.directory differently?”
  1. W. Michael PetulloJul 27, 2024
  2. Jeff KingJul 27, 2024
  3. W. Michael PetulloJul 28, 2024
  4. Jeff KingJul 28, 2024
  5. W. Michael PetulloJul 30, 2024
  6. brian m. carlsonJul 30, 2024
  7. Junio C HamanoJul 30, 2024
  8. Junio C HamanoJul 30, 2024
  9. brian m. carlsonJul 30, 2024
  10. Jeff KingJul 31, 2024
  11. Junio C HamanoJul 31, 2024
  12. Junio C HamanoJul 31, 2024
  13. Jeff KingAug 1, 2024
  14. Junio C HamanoAug 1, 2024
  15. brian m. carlsonAug 1, 2024
  16. Junio C HamanoAug 1, 2024
  17. Jeff KingAug 5, 2024
  18. W. Michael PetulloAug 5, 2024
  19. Junio C HamanoAug 5, 2024
  20. Jeff KingAug 1, 2024
  21. Jeff KingJul 31, 2024

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.