Re: drop tablespace failed when location contains .. on win32

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Michael Paquier <michael(at)paquier(dot)xyz>, "wangsh(dot)fnst(at)fujitsu(dot)com" <wangsh(dot)fnst(at)fujitsu(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: drop tablespace failed when location contains .. on win32
Date: 2021-09-09 12:30:29
Message-ID: 5dc0799e-82ab-cc86-6dc6-915412f2585a@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On 9/8/21 11:44 PM, Michael Paquier wrote:
> On Thu, Sep 09, 2021 at 02:35:52AM +0000, wangsh(dot)fnst(at)fujitsu(dot)com wrote:
>> Do you mean changing the action of canonicalize_path(), like remove all the (..) ?
>>
>> I'm willing to fix this problem.
> Looking at canonicalize_path(), we have already some logic around
> pending_strips to remove paths when we find a "/.." in the path, so
> that's a matter of adjusting this area to trim properly the previous
> directory.
>
> On *nix platforms, we don't apply this much caution either, say a
> simple /tmp/path/../path/ results in this same path used in the link
> from pg_tblspc. But we are speaking about Windows here, and junction
> points.
>
> Based on the lack of complains over the years, that does not seem
> really worth backpatching. Just my 2c on this point.

Maybe, although it's arguably a bug.

I think I would say that we should remove any "." or ".." element in the
path except at the beginning, and in the case of ".." also remove the
preceding element, unless someone can convince me that there's a problem
with that.

cheers

andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2021-09-09 12:30:51 Re: create table like: ACCESS METHOD
Previous Message Peter Eisentraut 2021-09-09 12:11:50 Re: Why does bootstrap and later initdb stages happen via client?