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