Re: Broken lock management in policy.c.

Tom,

On Sunday, January 3, 2016, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> CREATE POLICY takes AccessExclusiveLock on the table a policy is being
> added to -- good -- and then releases it when done -- bad. Correct
> behavior is to hold the lock till commit, because otherwise there is
> no guarantee that other backends will see the updated catalog rows in
> time, or indeed at all.

Agreed.

> The same goes for ALTER POLICY, and possibly DROP POLICY (I've not
> found the implementation of that ...)

DROP POLICY is handled through the generalized drop command and likely
doesn't have a problem due to that.

> If we fix this, I believe we could also remove the weasel wording that was
> added to create_policy.sgml in commit 43cd468cf01007f3 about how the
> system might transiently fail to enforce row security correctly.
>

The issue addressed there is with row locking, not table level locks. The
concern is that a user could acquire a lock on a row to which their access
to is then removed due to changes in rows which are used by the policy on
the table- not any changes to the policy definition itself. The row that is
locked might then be updated by the user who removed access to the row and
the results of that update seen by the original user via RETURNING.

Peter provided a test case which illustrated the concern.

http://www.postgresql.org/message-id/flat/20150803220725(dot)GB3587(at)tamriel(dot)snowman(dot)net

Apologies if the above isn't entirely accurate, on my phone at the moment.

Thanks!

Stephen