From: | Joe Conway <mail(at)joeconway(dot)com> |
---|---|
To: | David Wheeler <dwheeler(at)dgitsystems(dot)com>, "pgsql-general(at)lists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org> |
Cc: | Cameron Redpath <credpath(at)dgitsystems(dot)com> |
Subject: | Re: Permission inconsistency with views that call functions |
Date: | 2021-02-23 15:41:22 |
Message-ID: | 1ee7853f-806f-438f-25d5-16bc7eeeba11@joeconway.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 2/22/21 10:32 PM, David Wheeler wrote:
> I’m seeing some inconsistency with how permissions are enforced within views. In
> particular, if the view accesses a table directly, then the table is accessible,
> however if the view uses a function to access the table then permission is denied.
Without looking too closely at the details, I can almost guarantee that the
issue is that FUNCTIONs default to "SECURITY INVOKER" whereas VIEWs operate as
if they were "SECURITY DEFINER". See slide 33 here:
http://joeconway.com/presentations/security-pgcon2020.pdf
The solution to your issue is possibly to make the function "SECURITY DEFINER".
I have mused previously (not sure if I ever did on the lists, but in any case)
that it would be cool if VIEWs could have the option to be either DEFINER or
INVOKER so that VIEWs and FUNCTIONs could be treated the same, but no efforts
have been made in that direction as far as I am aware.
HTH,
Joe
--
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development
From | Date | Subject | |
---|---|---|---|
Next Message | Adrian Klaver | 2021-02-23 15:50:48 | Re: pg_restore - generated column - not populating |
Previous Message | Luka Zivkovic | 2021-02-23 15:40:42 | Re: New operators and class for jsonb with gin indexing |