From: Andreas Ericsson <ae@op5.se>
To: git@vger.kernel.org
Subject: Re: [PATCH 1/3] C implementation of the 'git' program, take two.
Date: Wed, 16 Nov 2005 01:42:15 +0100 [thread overview]
Message-ID: <437A8067.9050308@op5.se> (raw)
In-Reply-To: <Pine.LNX.4.64.0511151603510.11232@g5.osdl.org>
Linus Torvalds wrote:
>
> On Wed, 16 Nov 2005, Andreas Ericsson wrote:
>
>>+
>>+ /* allow relative paths, but run with exact */
>>+ if (chdir(exec_path)) {
>>+ printf("git: '%s': %s\n", exec_path, strerror(errno));
>>+ exit (1);
>>+ }
>>+
>>+ getcwd(git_command, sizeof(git_command));
>>+ chdir(wd);
>
>
> Argh. This is pretty horrible way to turn a path into an absolute one.
It was your idea to begin with, actually, in the thread on how to do
proper path validation in the git-daemon. :)
>
> Why don't you just do
>
> if (exec_path[0] != '/') {
> .. prepend "cwd/" to exec_path ..
>
You mean
setenv("PATH", concat3(cwd, exec_path, old_path), 1);
?
Because that can fail too. Every solution is bad if you twist and turn
it enough.
>
> The reason to avoid "chdir(relative) + chdir(back)" is that it totally
> unnecessarily breaks under some extreme cases. For example, if the
> exec_path is already absolute, and we just happen to be in a really deep
> subdirectory, then the getcwd() could have failed due to the PATH_MAX
> limitations.
>
True. So, would something like
char *try_goddamn_hard_to_get_working_dir(char *rel_path)
{
size_t plen = PATH_MAX;
char *p = malloc(PATH_MAX);
while(p && plen < 1 << 20 && !(p = getcwd(p, plen))) {
plen += PATH_MAX;
p = realloc(p, plen);
}
return p;
}
be considered safe from this particular point of view?
> Also, depending on getcwd() will not work if any parent directory is
> unreadable or non-executable (well, under Linux it will, as long as it's
> executable, since getcwd() is actually a system call. Not in UNIX in
> general, though). Again, that means that unless you _have_ to know what
> the cwd is, you should try to avoid relying on it.
>
True. I'll redo that part (tomorrow).
>
> and the nicer thign to do is to just not try to be clever.
>
I never try. It just comes to me naturally. ;)
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
next prev parent reply other threads:[~2005-11-16 0:42 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-15 23:31 [PATCH 1/3] C implementation of the 'git' program, take two Andreas Ericsson
2005-11-15 23:45 ` Junio C Hamano
2005-11-16 0:10 ` Andreas Ericsson
2005-11-16 0:17 ` Junio C Hamano
2005-11-16 0:18 ` Linus Torvalds
2005-11-16 0:42 ` Andreas Ericsson [this message]
2005-11-16 2:02 ` Linus Torvalds
2005-11-16 2:18 ` Johannes Schindelin
2005-11-16 21:04 ` Alex Riesen
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=437A8067.9050308@op5.se \
--to=ae@op5.se \
--cc=git@vger.kernel.org \
/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).