On Tue, Feb 9, 2016 at 4:22 PM, Tom Lane <t...@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.


> 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

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to