On 2014-10-29 10:47:58 -0400, Tom Lane wrote:
> Here is one trivial example: you want to let user joe import COPY
> data quickly, so you give him read access in directory foo, which he
> has write access on from his own account. Surely that's right in the
> middle of use cases you had in mind, or even if it wasn't, it sounds
> like a good idea no? The problem is he can create symlinks, not just
> files, in that directory, and by pointing the symlink to the right
> place he can read any file the server can read. pg_hba.conf, pg_authid,
> or even just tables he shouldn't have access to. With a little luck he
> can crack the superuser's password, but even without that you've given
> him access to sensitive information.
>
> If you were dumb enough to give joe *write* access in such a directory,
> so that he could COPY in both directions, it's game over altogether: he
> can become superuser in any number of ways, most easily by hacking
> pg_hba.conf.
>
> You could ameliorate this problem by checking to see that the read/write
> target is a file not a symlink, but that's still subject to filesystem
> race conditions that could be exploited by anyone with the ability to
> retry it enough times.
I think I'd be fair to restrict this features to platforms that support
O_NOFOLLOW and O_EXCL. Those can be used to circumvent such race
conditions.
> The larger point though is that this is just one of innumerable attack
> routes for anyone with the ability to make the server do filesystem reads
> or writes of his choosing. If you think that's something you can safely
> give to people you don't trust enough to make them superusers, you are
> wrong, and I don't particularly want to spend the next ten years trying
> to wrap band-aids around your misjudgment.
... but that doesn't necessarily address this point.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services