Sorry for the late reply, but I was on vacation (my 2. daughter was born).
> After looking at the rule rewriter some more, I realized that the only
> way to push all permissions checks to execution time is not
> only to keep
> skipAcl, but to generalize it. The problem is with checks on the view
> itself --- if you do INSERT INTO someView, which gets rewritten into
> an insert to someRealTable, then what you want the executor
> to check for
> is
> Write access on someView by current user
> Write access on someRealTable by owner of rule
> which is infeasible with the existing code because the executor only
> checks for write access on the real target table (someRealTable).
Which is iirc incorrect. It should only check write access to someView.
The checks for the someRealTable should be done as view owner.
Views are often used for horizontal permissions.
>
> What I have now got, and hope to commit today, is the following fields
> in RangeTblEntry, replacing skipAcl:
>
> * checkForRead, checkForWrite, and checkAsUser control
> run-time access
> * permissions checks. A rel will be checked for read
> or write access
> * (or both, or neither) per checkForRead and checkForWrite. If
> * checkAsUser is not InvalidOid, then do the
> permissions checks using
> * the access rights of that user, not the current
> effective user ID.
> * (This allows rules to act as setuid gateways.)
>
> bool checkForRead; /* check rel for read access */
> bool checkForWrite; /* check rel for write access */
> Oid checkAsUser; /* if not zero, check access
> as this user */
I don't know, but imho one field for all permissions would have been better,
like we discussed for the permissions system table, since there are more rights
in SQL than read/write (e.g. write is separated into insert, update and delete)
Or did I not understand this correctly ?
> NOTE: there is a subtle change here. A rule used to be taken as
> executing setUID to the owner of the table the rule is attached to.
> Now it is executed as if setUID to the person who created the rule,
> who could be a different user if the table owner gave away
> RULE rights.
> I think this is a more correct behavior, but I'm open to argument.
> It'd be easy to make CREATE RULE store the table owner's OID instead,
> if anyone wants to argue that that was the right thing.
No, I think setUID to rule creator is correct.
Andreas