Re: POC for a function trust mechanism

On Thu, Aug 9, 2018 at 04:01:09PM -0400, David Kohn wrote:
>
>
> 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

Look at your wording above, "I grant execute" --- you are opening up
permissions to them. There is no approval on their part that signifies
they should trust you. If I open permissions for a file on my web
server, it doesn't mean people should trust me more than before.

> 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.

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).

> 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. 

Yep.

> 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. 

You can't do that because if you do, someone creating a ambiguous
function would cause a denial-of-service attack --- better to fail at
the time of the first function, when you are likely watching the output.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +