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