Re: POC for a function trust mechanism

On Thu, Aug 9, 2018 at 12:11 PM Bruce Momjian <bruce(at)momjian(dot)us> wrote:

> ...
>
> > The things that we hadn't resolved, which is why this didn't get further
> > than POC stage, were
> >
> > (1) What's the mechanism for declaring trust? In this POC, it's just
> > a GUC that you can set to a list of role names, with $user for yourself
> > and "public" if you want to trust everybody. It's not clear if that's
> > good enough, or if we want something a bit more locked-down.
>
> Yes, works for me.
>
> > (2) Is trust transitive? Where and how would the list of trusted roles
> > change? Arguably, if you call a SECURITY DEFINER function, then once
> > you've decided that you trust the function owner, actual execution of the
> > function should use the function owner's list of trusted roles not yours.
> > With the GUC approach, it'd be necessary for SECURITY DEFINER functions
> > to implement this with a "SET trusted_roles" clause, much as they now
> > have to do with search_path. That's possible but it's again not very
> > non-invasive, so we'd been speculating about automating this more.
> > If we had, say, a catalog that provided the desired list of trusted roles
> > for every role, then we could imagine implementing that context change
> > automatically. Likewise, stuff like autovacuum or REINDEX would want
> > to run with the table owner's list of trusted roles, but the GUC approach
> > doesn't really provide enough infrastructure to know what to do there.
>
> I can't think of any other places we do transitive permissions, except
> for role membership. I don't see the logic in adding such transitivity
> to function/operator calls, or even a per-function GUC. I assume most
> sites have a small number of extensions installed by a predefined group
> of users, usually superusers. If there is a larger group, a group role
> should be created and those people put in the role, and the group role
> trusted.
>

I am wondering how this will interact with the inheritance of roles. For
instance, if two users are members of the same role, and one creates a
function the expectation would be that other users in the same role will
not trust that function. However, do I trust functions that are owned by
the roles that I am a member of? Or do I have to list any nested roles
explicitly? If the former, I suppose we'd have to modify how alter function
set owner works. It is currently allowed for roles that you are a member of
(and would then create a security hole). However, not trusting functions
owned by roles that I am a member of seems to also be a bit
counterintuitive.
Best,
David