Re: Permission inconsistency with views that call functions

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

In response to

Responses

Browse pgsql-general by date

  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