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@momjian.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 +