Bruce Momjian wrote:
> Bruce Momjian wrote:
> > Tom Lane wrote:
> > > Bruce Momjian writes:
> > > > Tom Lane wrote:
> > > >> Bruce Momjian writes:
> > > >>> I have reviewed is_absolute_path() and have implemented
> > > >>> path_is_relative_and_below_cwd() to cleanly handle cases like 'E:abc'
> >
Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian writes:
> > > Tom Lane wrote:
> > >> Bruce Momjian writes:
> > >>> I have reviewed is_absolute_path() and have implemented
> > >>> path_is_relative_and_below_cwd() to cleanly handle cases like 'E:abc' on
> > >>> Win32; patch attached.
> >
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> Bruce Momjian writes:
> >>> I have reviewed is_absolute_path() and have implemented
> >>> path_is_relative_and_below_cwd() to cleanly handle cases like 'E:abc' on
> >>> Win32; patch attached.
> >>
> >> This patch appears to remove
Bruce Momjian writes:
> Tom Lane wrote:
>> Bruce Momjian writes:
>>> I have reviewed is_absolute_path() and have implemented
>>> path_is_relative_and_below_cwd() to cleanly handle cases like 'E:abc' on
>>> Win32; patch attached.
>>
>> This patch appears to remove some security-critical restrict
Tom Lane wrote:
> Bruce Momjian writes:
> > I have reviewed is_absolute_path() and have implemented
> > path_is_relative_and_below_cwd() to cleanly handle cases like 'E:abc' on
> > Win32; patch attached.
>
> This patch appears to remove some security-critical restrictions.
> Why did you delete t
Bruce Momjian writes:
> I have reviewed is_absolute_path() and have implemented
> path_is_relative_and_below_cwd() to cleanly handle cases like 'E:abc' on
> Win32; patch attached.
This patch appears to remove some security-critical restrictions.
Why did you delete the path_contains_parent_refere
Bruce Momjian wrote:
> > However, it misses the case with for example E:foo, which is a perfectly
> > valid path on windows. Which isn't absolute *or* relative - it's relative
> > to the current directory on the E: drive. Which will be the same as the
> > current directory for the process *if* the
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> Hm. Neither of these obviously exclude the case of an absolute path
> >> that happens to lead to cwd. I'm not sure how important that is,
> >> but still ...
>
> > We currently do that with path_is_prefix_of_path(). Maybe that nee
Bruce Momjian writes:
> Tom Lane wrote:
>> Hm. Neither of these obviously exclude the case of an absolute path
>> that happens to lead to cwd. I'm not sure how important that is,
>> but still ...
> We currently do that with path_is_prefix_of_path(). Maybe that needs to
> be called as well.
I
Tom Lane wrote:
> Bruce Momjian writes:
> > Robert Haas wrote:
> >> Maybe something like is_under_cwd()?
>
> > Yeah, is_below_cwd?
>
> Hm. Neither of these obviously exclude the case of an absolute path
> that happens to lead to cwd. I'm not sure how important that is,
> but still ...
We curr
Bruce Momjian writes:
> Robert Haas wrote:
>> Maybe something like is_under_cwd()?
> Yeah, is_below_cwd?
Hm. Neither of these obviously exclude the case of an absolute path
that happens to lead to cwd. I'm not sure how important that is,
but still ...
regards, tom lane
Robert Haas wrote:
> On Tue, Jun 1, 2010 at 3:20 PM, Giles Lean wrote:
> > 1. is_relative_to_cwd() I continue to think is a bad name for something
> > ? concerned about ".." (plus on Windows not having a drive letter other
> > ? than the current one); the "normal" meaning of "relative path" is
> >
On Tue, Jun 1, 2010 at 3:20 PM, Giles Lean wrote:
> 1. is_relative_to_cwd() I continue to think is a bad name for something
> concerned about ".." (plus on Windows not having a drive letter other
> than the current one); the "normal" meaning of "relative path" is
> merely "not absolute"
May
Tom Lane wrote:
> Yeah. If we were to go with Greg's suggestion of inventing a separate
> is_relative_to_cwd test function, I'd expect that to insist on no ".."
> while it was at it.
So it's now two problems, and I think this is my final comment:
1. is_relative_to_cwd() I continue to think is
Bruce Momjian writes:
> Giles Lean wrote:
>> Names are hard, but if I understood the original post, the
>> revised function is intended to check that the directory is
>> below the current working directory.
> We check for things like ".." other places, though we could roll that
> into the macro i
Giles Lean wrote:
>
> Bruce Momjian wrote:
>
> > is_relative_to_cwd()?
>
> ../../../../some/other/place/not/under/cwd
>
> Names are hard, but if I understood the original post, the
> revised function is intended to check that the directory is
> below the current working directory.
We check fo
Bruce Momjian wrote:
> is_relative_to_cwd()?
../../../../some/other/place/not/under/cwd
Names are hard, but if I understood the original post, the
revised function is intended to check that the directory is
below the current working directory.
If my understanding is wrong (always possible!) a
Giles Lean wrote:
>
> Greg Stark wrote:
>
> > /* NOTE: these two functions aren't complementary under windows,
> > * be sure to use the right one */
> >
> > /* Check path always means the same thing regardless of cwd */
> > is_absolute_path()
> > /* Check that path is under cwd */
> > is_relat
Greg Stark wrote:
> /* NOTE: these two functions aren't complementary under windows,
> * be sure to use the right one */
>
> /* Check path always means the same thing regardless of cwd */
> is_absolute_path()
> /* Check that path is under cwd */
> is_relative_path()
Um ... isn't that second f
On Fri, Apr 9, 2010 at 2:16 PM, Magnus Hagander wrote:
>> I'm inclined to propose adding an additional path test operator, along
>> the lines of "has_drive_specifier(path)" (always false on non-Windows),
>> and use that where needed to reject relative-with-drive-letter paths.
>
> I think I agree w
Magnus Hagander wrote:
> Here's a thread that incorrectly started on the security list, but really is
> more about functionality. Looking for comments:
I looked into this and it seems to be a serious issue.
> The function is_absolute_path() is incorrect on Windows. As it's implemented,
> it consi
Magnus Hagander wrote:
> On Fri, Apr 9, 2010 at 16:02, Kevin Grittner
>> I assume we reject anything where what precedes the colon doesn't
>> match the current drive's designation?
>
> Define reject?
I guess I made that comment thinking about the example of usage
farther down.
> We're just
On Fri, Apr 9, 2010 at 16:02, Kevin Grittner
wrote:
> Magnus Hagander wrote:
>
>> it considers the following to be an absolute path:
>> * Anything that starts with /
>> * Anything that starst with \
>
> These aren't truly absolute, because the directory you find will be
> based on your current wo
Magnus Hagander wrote:
> it considers the following to be an absolute path:
> * Anything that starts with /
> * Anything that starst with \
These aren't truly absolute, because the directory you find will be
based on your current work directory's drive letter; however, if the
point is to then
Here's a thread that incorrectly started on the security list, but really is
more about functionality. Looking for comments:
The function is_absolute_path() is incorrect on Windows. As it's implemented,
it considers the following to be an absolute path:
* Anything that starts with /
* Anything tha
25 matches
Mail list logo
