From: | Achilleas Mantzios - cloud <a(dot)mantzios(at)cloud(dot)gatewaynet(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "pgsql-general(at)lists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Strange permission effect depending on DEFERRABILITY |
Date: | 2024-09-09 14:59:46 |
Message-ID: | e282efa2-f04e-d0a8-120a-35974f2bde53@cloud.gatewaynet.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 9/9/24 17:21, Tom Lane wrote:
> Achilleas Mantzios - cloud<a(dot)mantzios(at)cloud(dot)gatewaynet(dot)com> writes:
>> 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 strippedof 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.
> AFAIR the trigger mechanisms do not change the execution environment.
> If they did, then for example a trigger that stuffs CURRENT_USER into
> a last_updated_by column would not give the desired results.
>
> I'd suggest marking the problem trigger function as SECURITY DEFINER
> if you want it to run as its owner.
Thank you Tom. With a little bit of debugging is obvious that the last
deferred trigger function runs outside the security environment of the
top SECURITY DEFINER function (naturally), however current_user seems to
be on par with the security definer owner,
cbt_results_import(at)[local]/dynacom=> begin ;
BEGIN
cbt_results_import(at)[local]/dynacom=*> SET CONSTRAINTS zzzmariner_dmq_tg
IMMEDIATE;
SET CONSTRAINTS
cbt_results_import(at)[local]/dynacom=*> select
mariner_update_availability_date(13916, '2020-02-28');
NOTICE: manage past : the current_user is postgres, session_user is
cbt_results_import, system_user id md5:cbt_results_import
NOTICE: manage past : the current_user is postgres, session_user is
cbt_results_import, system_user id md5:cbt_results_import
mariner_update_availability_date
----------------------------------
(1 row)
cbt_results_import(at)[local]/dynacom=*> commit ;
COMMIT
cbt_results_import(at)[local]/dynacom=> begin ;
BEGIN
cbt_results_import(at)[local]/dynacom=*> SET CONSTRAINTS zzzmariner_dmq_tg
DEFERRED;
SET CONSTRAINTS
cbt_results_import(at)[local]/dynacom=*> select
mariner_update_availability_date(13916, '2020-02-28');
NOTICE: manage past : the current_user is postgres, session_user is
cbt_results_import, system_user id md5:cbt_results_import
mariner_update_availability_date
----------------------------------
(1 row)
cbt_results_import(at)[local]/dynacom=*> commit ;
NOTICE: manage past : the current_user is cbt_results_import,
session_user is cbt_results_import, system_user id md5:cbt_results_import
ERROR: permission denied for table export_dmq
CONTEXT: SQL statement "DELETE FROM export_dmq where id=($1).id and
op='U' and tbl='mariner'"
PL/pgSQL function export_dmq() line 18 at EXECUTE
Thank you and sorry for missing something so obvious.
>
> regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2024-09-09 15:00:12 | Re: infinite loop in an update statement |
Previous Message | Fabrice Chapuis | 2024-09-09 14:55:01 | infinite loop in an update statement |