From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Magnus Hagander <magnus(at)hagander(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: is_absolute_path incorrect on Windows |
Date: | 2011-02-04 21:53:17 |
Message-ID: | 201102042153.p14LrHw13613@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)us> writes:
> > Tom Lane wrote:
> >> Bruce Momjian <bruce(at)momjian(dot)us> 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_reference calls?
>
> > They are now in path_is_relative_and_below_cwd(),
>
> ... and thus not invoked in the absolute-path case. This is a security
> hole.
>
> > I don't see a general reason to prevent
> > ".." in absolute paths, only relative ones.
>
> load '/path/to/database/../../../path/to/anywhere'
Ah, good point. I was thinking about someone using ".." in the part of
the path that is compared to /data or /log, but using it after that
would clearly be a security problem.
I have attached an updated patch that restructures the code to be
clearer and adds the needed checks.
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
Attachment | Content-Type | Size |
---|---|---|
/rtmp/libpq.diff | text/x-diff | 6.4 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Grittner | 2011-02-04 22:27:15 | How to extract a value from a record using attnum or attname? |
Previous Message | Bruce Momjian | 2011-02-04 21:24:19 | Re: Per-column collation, the finale |