On 11/11/2013 06:37 PM, Kohei KaiGai wrote: > Hi Craig, > > I'd like to vote the last options. It is a separate problem (or, might > be specification), I think.
I tend to agree, but I'm nervous about entirely hand-waving around this, as doing so would *expand* the existing problem. "Solving" this properly would require adding a security context and current user to subqueries, not just for permissions checks (as currently exists) but for execution as well. That's a whole separate job. So I'd say that for first stage RS we should require that row-security policies only be defined by highly privileged users (superuser, or user granted a new SETROWSECURITY right). Table owners can't set row security on their own tables. That way we don't expand the existing security issue that already exists by making it easy to attack logical backups. Between that and the ability to grant a right that exempts users from row security (given to just superuser by default) we should be OK with this problem. Admins who choose to trust users not to write malicious RS predicates, or who only run pg_dump as superuser and have isolated users, can choose to grant their users the right to set their own row security policies. -- Craig Ringer 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