Joe Conway <m...@joeconway.com> writes:
> Personally I don't buy that the current situation is a good thing. I
> know that the "ship has sailed" and regret not having participated in
> the earlier discussions, but I agree with JD here -- the unprivileged
> user should not have to even think about whether RLS exists, they should
> only see what they have been allowed to see by the privileged users (and
> in the context of their own objects, owners are privileged). I don't
> think an unprivileged user should get to decide what code runs in order
> to make that happen.
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.
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.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
