Re: POC for a function trust mechanism

>
> We certainly don't want to double-down on extending trust by allowing
> someone to modify someone else's trusted role list. Practically, if you
> are opening up permissions to someone, you will need to create a group
> that you both belong to first, and have them trust the group, or they
> can trust you directly. The benefit of a group role is that other
> people can be added to that group without having to modify the trusted
> role list. Basically, the function caller is trusting whoever controls
> membership to that group role. This is different from having someone
> trusting a role just because they were added to it (perhaps without
> their knowledge).
>

I think if you trust a group role you are implicitly trusting any members
of that group, because one can always alter the function owner from
themselves to the group role, because they are a member of that group. So
what you'd need to do is create a special group role that only owned the
functions and then not make anyone an actual member of that group, but you
could trust that group role. Then a separate group role that everyone would
be a member of and you'd do grants from the first role to the second.
So for what you proposed, if you are opening up permissions to someone by
using a role that you are both members of, then you implicitly open up
permissions from them to you as well.

Anyway, I guess all of this seems to introduce a lot more complexity into
an already complex permissions management system...is this all about the
public schema? Can we just make create function/operator etc something you
have to grant even in the public schema? It seems like that could be
significantly more user friendly than this. Or otherwise, would functions
owned by the database or schema owner be exempt from this? Because there
are many setups where people try to avoid superuser usage by creating
database or schema owner users who can do things like create function,
which a normal users can now use. Would checks be skipped if the function
call is schema qualified because then there's no reasonable way to think
that someone is being fooled about which function they are executing?

Best,
David