Re: [GENERAL] Strange permission problem regarding pg_settings - Mailing list pgsql-hackers

From Joe Conway
Subject Re: [GENERAL] Strange permission problem regarding pg_settings
Date
Msg-id 3FEF390F.8050609@joeconway.com
Whole thread Raw
In response to Re: [GENERAL] Strange permission problem regarding pg_settings  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [GENERAL] Strange permission problem regarding pg_settings  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane wrote:
> No; it's possible for the amalgamated query to include references to
> tables that are referenced only in the original query and nowhere in the
> text of the rule.  (This is obviously possible right now, since we just
> take the union of the two rtables and don't make any effort to discard
> unreferenced RTEs ... but I think it could happen even if we did discard
> unreferenced RTEs, because conditions from the original query get pushed
> into the rule and might reference tables that the rule text doesn't
> mention.)  Checking such tables for rule-owner access would be wrong;
> they have to be checked for access by the rule caller.

OK, so the permission check performed on the original query RTEs, while 
executing the rule query is:
 1) redundant for non-INSTEAD cases
and 2) wrong if the original query and rule query are different modes

The patch at the root of this discussion eliminates both issues, but 
leaves us with no check at all in the INSTEAD case. Is there any way to 
do the permission checks on the original query in the INSTEAD case, even 
though the query itself will never be executed?

Joe




pgsql-hackers by date:

Previous
From: "Ramanujam H S Iyengar"
Date:
Subject: How to get oprname ??
Next
From: Tom Lane
Date:
Subject: Re: [GENERAL] Strange permission problem regarding pg_settings