On Thu, Aug 9, 2018 at 3:04 PM Bruce Momjian <bruce@momjian.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.
