Re: file_fdw target file ownership - Mailing list pgsql-hackers

From Daniel Vérité
Subject Re: file_fdw target file ownership
Date
Msg-id 87401d22-73dc-4320-8640-c72729547a95@mm
Whole thread Raw
In response to Re: file_fdw target file ownership  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: file_fdw target file ownership
List pgsql-hackers
   Tom Lane writes:

> Andres Freund <andres@2ndquadrant.com> writes:

> > One would be to use open(O_NOFOLLOW)?
>
> That would only stop symlink attacks, not hardlink variants;
> and it'd probably stop some legitimate use-cases too.

The creation of the hardlink is denied by the OS based on the
attacker not having sufficient permissions to the target file.
In principle the mentioned loophole is limited to a symlink, which
is not restricted at create time.

Thinking a bit more about the scenario of the malicious writer,
I think the secure way to proceed for the superuser would be to
set up two directories, one with write permissions to the
producer of data, the other without.

The superuser would have to move the file from the writable
dir to the non-writable dir, before creating the foreign table. The
file itself should remain writable by the uploader if it's live data.
The data-producer has to be aware that updates happen
at a different path than uploads.

The problem is that it's really not intuitive. I can imagine unaware
admins implementing the insecure process without a second thought.

By contrast, if symlinks were followed only optionally, it would
be safer as a default choice and the installations that need symlinks could
still use something like:

CREATE FOREIGN TABLE (...) SERVER name  OPTIONS (symlink_allowed 'on', filename '/path/to/file', ...)

The mere existence of the option is a  hint that there are consequences
to consider.

Best regards,
-- Daniel VéritéPostgreSQL-powered mail user agent and storage: http://www.manitou-mail.org



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [bug fix] strerror() returns ??? in a UTF-8/C database with LC_MESSAGES=non-ASCII
Next
From: Bruce Momjian
Date:
Subject: Re: strange IS NULL behaviour