Re: Strange permission effect depending on DEFERRABILITY
От | Achilleas Mantzios - cloud |
---|---|
Тема | Re: Strange permission effect depending on DEFERRABILITY |
Дата | |
Msg-id | 40558bdd-d641-feac-84fe-65b3e87ec085@cloud.gatewaynet.com обсуждение исходный текст |
Ответ на | Re: Strange permission effect depending on DEFERRABILITY (Laurenz Albe <laurenz.albe@cybertec.at>) |
Ответы |
Re: Strange permission effect depending on DEFERRABILITY
|
Список | pgsql-general |
On 9/10/24 00:09, Laurenz Albe wrote: > On Mon, 2024-09-09 at 16:14 +0300, Achilleas Mantzios - cloud wrote: >> The below runs on PostgreSQL 16.4 >> >> We are trying to implement a certain operation based on a security definer >> function : mariner_update_availability_date >> >> This is supposed to update a table : mariner , which has several other triggers : >> >> [...] >> zzzmariner_dmq_tg AFTER INSERT OR DELETE OR UPDATE ON mariner DEFERRABLE INITIALLY DEFERRED FOR EACH ROW EXECUTE FUNCTIONexport_dmq() >> >> As you noticed the last trigger is a CONSTRAINT DEFERRABLE trigger. >> This function mariner_update_availability_date is supposed to be run by a user : >> cbt_results_import stripped of any privileges to the rest of the system. Here is >> what we get : when we SET the constraint of the last trigger to IMMEDIATE, the >> function runs on behalf of its owner (postgres) who has all needed privileges >> (as superuser) to run the update on mariner table and also run the triggers . >> However, when we run with this CONSTRAINT as DEFERRED then it seems to NOT run >> the last deferrable trigger as postgres. > I have proposed a patch that fixes exactly that case: > https://commitfest.postgresql.org/49/4888/ > > So far, the feedback seems to be that it is not considered a bug. > But that doesn't mean that we cannot change the behavior. Nice work! However I am not sure. What's a trigger owner btw in the thread : https://www.postgresql.org/message-id/flat/77b89e609f21380785865542609fbc14010021c8.camel%40cybertec.at#3d6e4f8fc8872e37f37a75d5e0082e0b ? Do they mean the table owner? is the trigger creator / owner stored somewhere ? I dont see it in system tables or the schema dump. Or do they imply the trigger function owner ? Maybe controlling the queued and later executed trigger invocations security context via a new special GUC? such as : trigger_security_ctx = current_user (default) | table/trigger_owner | execution_triggered_user (in every case a SECURITY DEFINER function would override the above setting) just my 2cents > Yours, > Laurenz Albe
В списке pgsql-general по дате отправления: