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 (zmp...@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
signature.asc
Description: Digital signature
