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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
