Re: POC for a function trust mechanism - Mailing list pgsql-hackers

From David Kohn
Subject Re: POC for a function trust mechanism
Date
Msg-id CAJhMaBgZMov=u4aOi+VPdOyf_fgrcnUwgEZ6DtOQK32Rv=5gLA@mail.gmail.com
Whole thread Raw
In response to Re: POC for a function trust mechanism  (Bruce Momjian <bruce@momjian.us>)
Responses Re: POC for a function trust mechanism
Re: POC for a function trust mechanism
List pgsql-hackers
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

pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: CF 2018-07 Needs Review items
Next
From: Alvaro Herrera
Date:
Subject: Re: Commitfest 2018-07 WOA items