Re: Directory/File Access Permissions for COPY and Generic File Access Functions - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Directory/File Access Permissions for COPY and Generic File Access Functions
Date
Msg-id 27383.1414603419@sss.pgh.pa.us
Whole thread Raw
In response to Re: Directory/File Access Permissions for COPY and Generic File Access Functions  (Stephen Frost <sfrost@snowman.net>)
Responses Re: Directory/File Access Permissions for COPY and Generic File Access Functions
Re: Directory/File Access Permissions for COPY and Generic File Access Functions
List pgsql-hackers
Stephen Frost <sfrost@snowman.net> writes:
> * Tom Lane (tgl@sss.pgh.pa.us) wrote:
>> This points up the fact that platform-specific security holes are likely
>> to be a huge part of the problem.  I won't even speculate about our odds
>> of building something that's secure on Windows.

> Andres' suggestion to only provide it on platforms which support
> O_NOFOLLOW and O_EXCL certainly seems appropriate, along with fstat'ing
> after we've opened it and checking that there's only one hard-link to
> it.  As for Windows, it looks like you can get a file's attributes after
> opening it by using GetFileInformationByHandle and you can then check if
> it's a junction point or not (which would indicate if it's either a
> symbolic link or a hard link, from what I can see).  Obviously, we'd
> need to get input from someone more familiar with Windows than I am
> before we can be confident of this approach though.

So at this point we've decided that we must forbid access to symlinked or
hardlinked files, which is a significant usability penalty; we've also
chosen to blow off most older platforms entirely; and we've only spent
about five minutes actually looking for security issues, with no good
reason to assume there are no more.

(I can think of one more already, actually: the proposed post-open
fstat for link count has a race condition.  User just has to link target
file into writable directory, attempt to open it, and concurrently unlink
from the writable directory.  Repeat until success.)

So I remain of the opinion that this is a bad idea we should not pursue.
We're going to put a huge amount of work into it, it *will* cause more
than one security bug in the future (want to lay a side bet?), and we're
still going to end up with people needing to use the old-style access
facilities because the restrictions we'll have to put on this one are
unacceptable for their purposes.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: Directory/File Access Permissions for COPY and Generic File Access Functions
Next
From: Stephen Frost
Date:
Subject: Re: Materialized views don't show up in information_schema