Re: RLS open items are vague and unactionable

On Fri, Sep 11, 2015 at 7:33 AM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> I've updated the page to add more details about the various items,
> though the only code changes at this point considered 'open' are this
> refactoring and the question regarding the 'row-level-security disabled'
> context which I posted a patch for discussion yesterday.
>
> Comments and help on these would certainly be welcome, of course. We're
> working on a set of documentation updates to hopefully finish up in the
> next week to add more details about RLS (additional sub-sections,
> coverage of the issue Peter raised, additional discussion of RETURNING,
> etc).

Thanks for the updates. My thoughts:

On RETURNING, it seems like we've got a fairly fundamental problem
here. If I understand correctly, the intention of allowing policies
to be filtered by command type is to allow blind updates and deletes,
but this behavior means that they are not really blind. You can
always use BEGIN/UPDATE-or-DELETE-with-RETURNING/ROLLBACK as a
substitute for SELECT. So the only possible thing you can do with the
ability to filter by command tag that is coherent from a security
point of view is to make the update and delete predicates *tighter*
than the select predicate.

And if that's where we end up, then haven't we fundamentally
mis-designed the feature? I mean, without the blind update case, it
just seems kooky to have different commands see different rows. It
would be better to have all the command see the same rows, and then
have update/delete *error out* if you try to update a row you're not
allowed to touch.

On Dean's refactoring patch, I would tend to favor back-patching
whatever do there to 9.5, but I'm not volunteering to do the work.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company