git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCHv3 2/5] Learn to handle gitfiles in enter_repo
@ 2011-10-05 13:31 Phil Hord
  2011-10-06  3:11 ` Nguyen Thai Ngoc Duy
  0 siblings, 1 reply; 3+ messages in thread
From: Phil Hord @ 2011-10-05 13:31 UTC (permalink / raw)
  To: git@vger.kernel.org, Phil Hord
  Cc: Junio C Hamano, Erik Faye-Lund, Nguyen Thai Ngoc Duy

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>

---

Not sure how to resolve this 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 administator might
   not be aware.


diff --git a/path.c b/path.c
index f3d96aa..46ba326 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] == '/'))
@@ -330,7 +331,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.505.ga09f6

^ permalink raw reply related	[flat|nested] 3+ messages in thread

* Re: [PATCHv3 2/5] Learn to handle gitfiles in enter_repo
  2011-10-05 13:31 [PATCHv3 2/5] Learn to handle gitfiles in enter_repo Phil Hord
@ 2011-10-06  3:11 ` Nguyen Thai Ngoc Duy
  2011-10-06 19:16   ` Phil Hord
  0 siblings, 1 reply; 3+ messages in thread
From: Nguyen Thai Ngoc Duy @ 2011-10-06  3:11 UTC (permalink / raw)
  To: Phil Hord; +Cc: git@vger.kernel.org, Phil Hord, Junio C Hamano, Erik Faye-Lund

On Thu, Oct 6, 2011 at 12:31 AM, Phil Hord <hordp@cisco.com> wrote:
> -               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;
>        }

This is room for improvement, the patch is fine as it is now. We could
improve error reporting here. If .git file points to nowhere, we get
"not a repository-kind of message. Except daemon.c, enter_repo()
callers always die() if enter_repo() returns NULL. We could move the
die() part (with improved error message) into enter_repo().

We could update enter_repo(const char *, int) to enter_repo(const char
*, int, int gently). If gently is 1, we never die() nor report
anything (ie. what we're doing now). daemon.c will need this, the rest
of callers will be happy with gently = 0.
-- 
Duy

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCHv3 2/5] Learn to handle gitfiles in enter_repo
  2011-10-06  3:11 ` Nguyen Thai Ngoc Duy
@ 2011-10-06 19:16   ` Phil Hord
  0 siblings, 0 replies; 3+ messages in thread
From: Phil Hord @ 2011-10-06 19:16 UTC (permalink / raw)
  To: Nguyen Thai Ngoc Duy
  Cc: git@vger.kernel.org, Phil Hord, Junio C Hamano, Erik Faye-Lund

Nguyen Thai Ngoc Duy <pclouds@gmail.com> says,
> On Thu, Oct 6, 2011 at 12:31 AM, Phil Hord <hordp@cisco.com> wrote:
>> -               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;
>>        }
> 
> This is room for improvement, the patch is fine as it is now. We could
> improve error reporting here. If .git file points to nowhere, we get
> "not a repository-kind of message. Except daemon.c, enter_repo()
> callers always die() if enter_repo() returns NULL. We could move the
> die() part (with improved error message) into enter_repo().
> 
> We could update enter_repo(const char *, int) to enter_repo(const char
> *, int, int gently). If gently is 1, we never die() nor report
> anything (ie. what we're doing now). daemon.c will need this, the rest
> of callers will be happy with gently = 0.

I like that.  It wasn't clear to me what the 'gently' moniker meant
before, but now I understand it.  It could easily apply to this function
and the new is_gitfile() to help reduce code duplication.

In a different patch, though.

Phil

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2011-10-06 19:16 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-10-05 13:31 [PATCHv3 2/5] Learn to handle gitfiles in enter_repo Phil Hord
2011-10-06  3:11 ` Nguyen Thai Ngoc Duy
2011-10-06 19:16   ` Phil Hord

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).