From: Phil Hord <hordp@cisco.com>
To: "git@vger.kernel.org" <git@vger.kernel.org>,
Phil Hord <phil.hord@gmail.com>
Cc: Junio C Hamano <gitster@pobox.com>,
Erik Faye-Lund <kusmabite@gmail.com>,
Nguyen Thai Ngoc Duy <pclouds@gmail.com>
Subject: [PATCHv3 2/5] Learn to handle gitfiles in enter_repo
Date: Wed, 05 Oct 2011 09:31:26 -0400 [thread overview]
Message-ID: <4E8C5C2E.50309@cisco.com> (raw)
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
next reply other threads:[~2011-10-05 13:36 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-05 13:31 Phil Hord [this message]
2011-10-06 3:11 ` [PATCHv3 2/5] Learn to handle gitfiles in enter_repo Nguyen Thai Ngoc Duy
2011-10-06 19:16 ` Phil Hord
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=4E8C5C2E.50309@cisco.com \
--to=hordp@cisco.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=kusmabite@gmail.com \
--cc=pclouds@gmail.com \
--cc=phil.hord@gmail.com \
/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 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).