Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
Tom Lane wrote:
... it's part of the API contract of canonicalize_path() that it
will not return something with trailing . or ...
OK, new patch which I think handles all cases.
+ if (pending_strips 0)
+ {
+
Bruce Momjian pgman@candle.pha.pa.us writes:
Tom Lane wrote:
Uh, that hardly meets the API contract that I mentioned. I think
we really have to throw an error if the path tries to .. above
the starting point.
OK, so how do you want to error out? exit()? There are no ereport
calls in that
Tom Lane wrote:
I wrote:
Uh, that hardly meets the API contract that I mentioned. I think
we really have to throw an error if the path tries to .. above
the starting point.
After rereading all the callers of canonicalize_path, I've concluded
that none of them actually depend on not
I wrote:
Uh, that hardly meets the API contract that I mentioned. I think
we really have to throw an error if the path tries to .. above
the starting point.
After rereading all the callers of canonicalize_path, I've concluded
that none of them actually depend on not having a terminating ..
as
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
OK, here is a version that errors out that I just applied and reversed
out when I saw your email. Feel free to use it or discard it.
Sorry about that --- should have tried to mail you a bit sooner.
BTW, what's with the
Bruce Momjian pgman@candle.pha.pa.us writes:
In my first attempt, I counted the number of .. groups, then went up
to remove each .., and them remove a regular directory for each ...
And then you have this case:
/usr/local/../bin/../..
Here you hit the first .. as you are going up. It
What if we let the trailing . or .. as it is?
On Windows, GetFullPathName() can canonicalize a given path.
$ uname -a
MINGW32_NT-5.0 DEV 1.0.10(0.46/3/2) 2003-10-11 10:14 i686 unknown
$ cat path.c
#include windows.h
int
main(void)
{
CHAR Buf[1024];
GetFullPathName(C:\\Temp,
Yep, it is a bug on 8.0.X. Are you suggesting a backpatch? We can do
it. Any objections?
---
William ZHANG wrote:
What if we let the trailing . or .. as it is?
On Windows, GetFullPathName() can canonicalize a given
Bruce Momjian pgman@candle.pha.pa.us writes:
Yep, it is a bug on 8.0.X. Are you suggesting a backpatch? We can do
it. Any objections?
I think he's suggesting that we depend on GetFullPathName(), which seems
a bit pointless considering we have to write the code anyway for other
platforms.
I
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
Yep, it is a bug on 8.0.X. Are you suggesting a backpatch? We can do
it. Any objections?
I think he's suggesting that we depend on GetFullPathName(), which seems
a bit pointless considering we have to write the code anyway
- Original Message -
From: Tom Lane [EMAIL PROTECTED]
To: Bruce Momjian pgman@candle.pha.pa.us
Cc: William ZHANG [EMAIL PROTECTED]; pgsql-patches@postgresql.org
Sent: Friday, August 12, 2005 10:31 AM
Subject: Re: [PATCHES] Bug in canonicalize_path()
Bruce Momjian pgman
I wrote:
I didn't much like the patch as-is; we should think a little harder
about fixing the logic properly.
Like, say, this. (Very poorly tested but I think it's right.)
regards, tom lane
*** src/port/path.c.origThu Aug 11 21:39:22 2005
--- src/port/path.c
Bruce Momjian pgman@candle.pha.pa.us writes:
And then you have this case:
/usr/local/../bin/../..
AFAICS, the patch I just proposed handles this.
If I recall the code properly, we do not have to make canonicalize_path
remove embedded . or .. --- that is, we do not have to simplify
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
And then you have this case:
/usr/local/../bin/../..
AFAICS, the patch I just proposed handles this.
If I recall the code properly, we do not have to make canonicalize_path
remove embedded . or .. --- that is, we do not
Bruce Momjian pgman@candle.pha.pa.us writes:
But what about usr/local/../../..?
What about it? The case of /usr/local/../../.. is handled correctly,
and the case where it's an underspecified relative path doesn't seem
that interesting to me --- certainly that is not so important that we
should
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
But what about usr/local/../../..?
What about it? The case of /usr/local/../../.. is handled correctly,
and the case where it's an underspecified relative path doesn't seem
that interesting to me --- certainly that is not so
pgman@candle.pha.pa.us
To: Tom Lane [EMAIL PROTECTED]
Cc: William ZHANG [EMAIL PROTECTED]; pgsql-patches@postgresql.org
Sent: Friday, August 12, 2005 11:15 AM
Subject: Re: [PATCHES] Bug in canonicalize_path()
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
But what about usr/local
Bruce Momjian pgman@candle.pha.pa.us writes:
I figured it would be best to leave it alone if we can't process it, but
if you think it is more imporant to trim in cases like ../.., go ahead.
My recollection of this patch:
2004-08-09 16:20 tgl
* src/: port/exec.c, port/path.c,
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
I figured it would be best to leave it alone if we can't process it, but
if you think it is more imporant to trim in cases like ../.., go ahead.
My recollection of this patch:
2004-08-09 16:20 tgl
* src/:
Bruce Momjian pgman@candle.pha.pa.us writes:
Tom Lane wrote:
... it's part of the API contract of canonicalize_path() that it
will not return something with trailing . or ...
OK, new patch which I think handles all cases.
+ if (pending_strips 0)
+ {
+ for (;
20 matches
Mail list logo
