Re: POC for a function trust mechanism

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

>
>
> Well, right now, if you want to give members of a role rights to
> something, you have to specifically grant rights to that role. I would
> assume the same thing would happen here --- if you want to trust a group
> role, you have to mention that group role in the GUC list (not
> function-level GUC).

Sure, but if I grant execute on a function to a role, members of that role
will be able to execute that function. Now, each member will (potentially)
need to update their trust list before doing that. Which seems a bit odd.
Or will I be able to modify the some sort of default trust list of the
group role? If not, it seems like it could be an administrative nightmare,
if so there are potential issues with who is allowed to modify the list of
trusted users that then gets inherited.

> ...
>
> Basically, as it is now, someone adding me to their role membership has
> no downside for me. To trust my own role membership adds a downside to
> role membership that I don't think we want to do --- it makes role
> membership too complex in what it grants _and_ trusts.
>
> Makes sense, and I can see how that could get out of hand in terms of
figuring out who you trust. I guess I don't know of other cases where this
concept of trusting comes about in our current permissions system? And it
seems to introduce a lot of odd cases where you end up with a sort of
permissions error or I guess a trust error in this case.

One possibility that might help this would be to only use the check this if
a) the user who created the function isn't in the trust list and b) there
is a function with the same name and equivalent argument classes that would
be called if you weren't to call the untrusted user's function. So it is
only used for disambiguation.

Best,
David