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