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

Re: Git clone reads safe.directory differently?

From
Jeff King <peff@peff.net>
Date
Aug 1, 2024, 06:14 UTC
Message-ID
<20240801061417.GD621899@coredump.intra.peff.net>
In-Reply-To
<xmqq1q391afc.fsf@gitster.g>
On Wed, Jul 31, 2024 at 03:08:55PM -0700, Junio C Hamano wrote:
Show 12 quoted lines
> Junio C Hamano <gitster@pobox.com> writes:
> 
> > So we probably need to add another axis to the "strict" parameter
> > enter_repo() takes to selectively disable the ownership checks only
> > for upload-pack, or something like that.
> 
> So, here is a rough sketch for the above.  Interested parties may
> build on top of it, perhaps by adding separate knobs to loosen or
> tighten the second parameter given to enter_repo() at different
> callsites, by writing tests to make sure they work as intended, and
> by documenting the security story around it none of which I do here
> ;-).
This looks roughly like I'd expect, but...
Show 23 quoted lines
> diff --git c/builtin/upload-pack.c w/builtin/upload-pack.c
> index 46d93278d9..fe50ce3eed 100644
> --- c/builtin/upload-pack.c
> +++ w/builtin/upload-pack.c
> @@ -36,6 +36,7 @@ int cmd_upload_pack(int argc, const char **argv, const char *prefix)
>  			    N_("interrupt transfer after <n> seconds of inactivity")),
>  		OPT_END()
>  	};
> +	unsigned enter_repo_flags = ENTER_REPO_ANY_OWNER_OK;
>  
>  	packet_trace_identity("upload-pack");
>  	disable_replace_refs();
> @@ -51,7 +52,9 @@ int cmd_upload_pack(int argc, const char **argv, const char *prefix)
>  
>  	dir = argv[0];
>  
> -	if (!enter_repo(dir, strict))
> +	if (strict)
> +		enter_repo_flags |= ENTER_REPO_STRICT;
> +	if (!enter_repo(dir, enter_repo_flags))
>  		die("'%s' does not appear to be a git repository", dir);
>  
>  	switch (determine_protocol_version_server()) {

...this is doing that loosening for upload-pack by default. I'm not sure if that is OK or not. My mental model has remained "it is OK to run upload-pack on an untrusted repository", but it would make sense to get input from folks who looked at this in the past, like Dscho, and/or to reassess the threat model from scratch.

In particular I did not follow all of the potential issues with linked local files. Are we good now after other fixes (in which case this patch is OK)? Are we good only for non-local clones (so this patch is OK only combined with a fix for clone to check ownership for --local mode)? Or are there still problems if an attacker controls the repo paths, in which case upload-pack should remain conservative?

-Peff
Previous: Junio C HamanoNext: Junio C Hamano
Message 13 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.