Re: Directory/File Access Permissions for COPY and Generic File Access Functions

Stephen Frost <sfrost(at)snowman(dot)net> writes:
> * Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)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