Re: CREATE POLICY and RETURNING - Mailing list pgsql-hackers

Zhaomo,

Just a side-note, but your mail client doesn't seem to get the quoting
quite right sometimes, which can be confusing.  Not sure if there's
anything you can do about it but wanted to let you know in case there
is.

* Zhaomo Yang (zmpgzm@gmail.com) wrote:
> > It'd be great if others who are interested can help define the grammar
> > changes necessary
> > and perhaps even help with the code aspect of it.
>
> I'd like to help on both. Can you elaborate a little bit more, especially
> on the code aspect?

There's a fair bit of information available regarding how to contribute
code on the wiki; here's a few links:

https://wiki.postgresql.org/wiki/Development_information
https://wiki.postgresql.org/wiki/Developer_FAQ
https://wiki.postgresql.org/wiki/Submitting_a_Patch

Regarding this, specifically, we'd need to first decide on what the
syntax/grammar should be.  Right now we have, at a basic level:

CREATE POLICY <name> ON <table> USING (<expression>);

To define restrictive policies we'd need a new bit of syntax which says
"this policy should be restrictive instead of permissive."  One approach
to that would be:

CREATE RESTRICTIVE POLICY ...

but my initial hunch is that we'd rather have something like:

CREATE POLICY <name> ON <table> RESTRICTIVE USING (<expression);

or something along those lines.  At some point, the actual grammar
(expressed in gram.y) has to be modified.  One other point to be aware
of is that the grammar can't be ambiguous or we can end up with
shift/shift or shift/reduce conflicts when building the actual code that
runs the grammar.  There's a whole lot which could be explained about
just what that means, but a quick summary is "avoid things like this:"

Having productions which are like this:

CREATE POLICY <p1> ON <table> USING (<expression>);
CREATE POLICY RESTRICTIVE <p1> ON <table> USING (<expression>);

as that means that we have to make RESTRICTIVE be reserved, to make sure
we know if it's a keyword (as in the second example above) or actually a
policy name (as in the first example above).  This is a pretty gross
over-simplification, and the above might even work (I've not tried it),
but hopefully it gets the point across.

> > I don't buy that argument.
>
> It is agreed that blind updates and deletes with RETURNING clause are
> dangerous. It is quite similar here.

Right, and we adressed the concerns with RETURNING.  Regarding the
non-RETURNING case, The same concerns about blind updates and deletes
already exist with the GRANT permission system; it's not anything new.

> Instead of using
>    BEGIN
>    UPDATE-or-DELETE-with-RETURNING
>    ROLLBACK
> as a substitute for SELECT, a malicious user can do a binary search with
> some trick like divide-by-zero
> to figure out rows he is not allowed to access. Of course, this is not as
> serious as RETURNING, but it is still quite convenient for attackers.

This is true of the current GRANT system.

Thanks!

Stephen