Re: POC for a function trust mechanism

On Thu, Aug 9, 2018 at 06:18:16PM -0400, David Kohn wrote:
> 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

Good point. I think you are right that if you trust a role, you trust
whoever controls role membership to add only trust-worthy people --- that
seems obvious because any member can create functions you will trust,
even if they don't change the function owner.

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

I don't see the value in that. My point is that you can't trust anyone
in a role you are a member of, by default --- you have to make that
decision as a user.

> 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

I think 95% of users are proabably creating these things as the
accessing user or super-user.

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

I think most setups will be pretty simple.

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