Thanks for the reply > VIEWs operate as if they were "SECURITY DEFINER".
My concern is that the view is not acting as a security barrier underneath which all access is evaluated using the view owner context; in some circumstances (when the view calls a function) the access is evaluated using the caller’s context. Caller | | V - View -------------- Security definition layer | |---- (b) | | (a)| v | Function (not SECURITY DEFINER or explicitly SECURITY INVOKER) | | | | | | V x Table I would expect that everything underneath the View would use the view owner to evaluate permissions. However it seems that in scenario (b) it enters a new security context from the caller, rather than inheriting it from the view. > The solution to your issue is possibly to make the function "SECURITY > DEFINER". This works, but I see this as a workaround, because the function is simply a utility that makes understanding the data in the table a little easier. Why should it be security definer? If you don’t have access to the table you shouldn’t be able to use the function to access it. Regards, David On 24/2/21, 2:41 am, "Joe Conway" <m...@joeconway.com> wrote: 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
