| From: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
|---|---|
| To: | o(dot)tselebrovskiy(at)postgrespro(dot)ru |
| Cc: | pgsql-hackers(at)postgresql(dot)org, s(dot)shinderuk(at)postgrespro(dot)ru, Amit Langote <amitlangote09(at)gmail(dot)com> |
| Subject: | Re: A bug with ExecCheckPermissions |
| Date: | 2023-02-08 10:49:00 |
| Message-ID: | 20230208104900.fvpikobjumzwqkk3@alvherre.pgsql |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2023-Feb-08, o(dot)tselebrovskiy(at)postgrespro(dot)ru wrote:
> But if you debug function ExecCheckPermissions and look into what is passed
> to function (contents of rangeTable and rteperminfos to be exact),
> you'll see some strange behaviour:
> Both of RangeTableEntries have a perminfoindex of 0 and simultaneously have
> a RTEPERMISSIONINFO entry for them!
Ouch. Yeah, that's not great. As you say, it doesn't really affect
anything, and we know full well that these RTEs are ad-hoc
manufactured. But as we claim that we still pass the RTEs for the
benefit of hooks, then we should at least make them match.
I think we should also patch ExecCheckPermissions to use forboth(),
scanning the RTEs as it goes over the perminfos, and make sure that the
entries are consistent.
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Nazir Bilal Yavuz | 2023-02-08 10:49:37 | REASSIGN OWNED vs ALTER TABLE OWNER TO permission inconsistencies |
| Previous Message | Peter Eisentraut | 2023-02-08 10:45:05 | meson: Non-feature feature options |