On Tue, Feb 9, 2016 at 4:22 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Part of the problem here is that we have *not* created any hard and fast
> distinction between "privileged" and "unprivileged" users; I think that
> even speaking in those terms about RLS risks errors in your thinking.
+1.
> In particular, the code-execution issue arises from the fact that a table
> owner can now cause code to execute *with the permissions of someone else*
> if the someone else is foolish enough to select from his table. No
> special privileges required, just the ability to create a table. If we
> make pg_dump run with RLS enabled, then the "foolish" part doesn't need to
> be any more foolish than forgetting a -t switch when using pg_dump.
Yes. That is exactly why I argued for the current situation to be the
way it is, and I think it would have been a huge mistake if we now
decided otherwise. I don't have a ton of confidence that the database
is free of problems that would allow one user to assume the privileges
of another - but I certainly don't want to design more such problems
into the server.
> Maybe we need to restrict that somehow, or maybe some better solution
> exists that we've not thought of yet. But in its current state, RLS
> is at least as much a security hazard as it is a security aid.
> I do not want to see it extended in ways that make pg_dump unsafe to
> use.
I could not agree more.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company