[PATCH 2/4] Learn to handle gitfiles in enter_repo

Phil Hord· Oct 4, 2011, 20:05 UTC · lore

The enter_repo() function is used to navigate into a .git directory. It knows how to find standard alternatives (DWIM) but it doesn't handle gitfiles created by git init --separate-git-dir. This means that git-fetch and others do not work with repositories using the separate-git-dir mechanism.

Teach enter_repo() to deal with the gitfile mechanism by resolving the path to the redirected path and continuing tests on that path instead of the found file.

Signed-off-by: Phil Hord <hordp@cisco.com>
---

This change allows enter_repo to work with gitfiles, but another change is required to teach transport.c to recognize gitfiles as git-dirs.

Show changes to path.c +7 −1

diff --git a/path.c b/path.c
index 01028f2..b6f71d1 100644
--- a/path.c
+++ b/path.c
@@ -295,6 +295,7 @@ const char *enter_repo(const char *path, int strict)
 		static const char *suffix[] = {
 			".git/.git", "/.git", ".git", "", NULL,
 		};
+		const char *gitfile;
 		int len = strlen(path);
 		int i;
 		while ((1 < len) && (path[len-1] == '/'))
@@ -329,7 +330,12 @@ const char *enter_repo(const char *path, int strict)
 				break;
 			}
 		}
-		if (!suffix[i] || chdir(used_path))
+		if (!suffix[i])
+			return NULL;
+		gitfile = read_gitfile(used_path) ;
+		if (gitfile)
+			strcpy(used_path, gitfile);
+		if (chdir(used_path))
 			return NULL;
 		path = validated_path;
 	}

-- 
1.7.7.503.g26392.dirty

Phil Hord· Oct 4, 2011, 20:13 UTC · re: Phil Hord · lore

Re: [PATCH 2/4] Learn to handle gitfiles in enter_repo

On Tue, Oct 4, 2011 at 4:05 PM, Phil Hord <phil.hord@gmail.com> wrote:

Show 13 quoted lines

> The enter_repo() function is used to navigate into a .git
> directory.  It knows how to find standard alternatives (DWIM) but
> it doesn't handle gitfiles created by git init --separate-git-dir.
> This means that git-fetch and others do not work with repositories
> using the separate-git-dir mechanism.
>
> Teach enter_repo() to deal with the gitfile mechanism by resolving
> the path to the redirected path and continuing tests on that path
> instead of the found file.
>
> Signed-off-by: Phil Hord <hordp@cisco.com>
> ---
>

I meant to include this note on this patch. Maybe I should have added an RFC, too.

I'm not sure how to resolve this change for the 'strict' case.

The actual path followed may be different than the version spelled out on the input path because of resolved symlinks and whatnot. This function normally returns the unmolested "original" path that was validated. In case of a gitfile, I think that means we should return the url resolved from the gitfile contents.

But should we?

The returned path is only used in git-daemon where it gets further checks for path restrictions.

A. If we return the gitfile-resolved path, this may cause these
   path restrictions to fail since the path gets canonicalized
   when the gitfile is created by git.

B. If we do not return the gitfile-resolved path, this can create
   a security-hole by allowing remote users to access files they
   would otherwise have been restricted from.  In effect it creates
   an alternate symlink mechanism of which the administrator might
   not be aware.

patch, 4 partsLearn to handle gitfiles in enter_repo