On Thu, Aug 9, 2018 at 12:11 PM Bruce Momjian <br...@momjian.us> wrote:
> ... > > > The things that we hadn't resolved, which is why this didn't get further > > than POC stage, were > > > > (1) What's the mechanism for declaring trust? In this POC, it's just > > a GUC that you can set to a list of role names, with $user for yourself > > and "public" if you want to trust everybody. It's not clear if that's > > good enough, or if we want something a bit more locked-down. > > Yes, works for me. > > > (2) Is trust transitive? Where and how would the list of trusted roles > > change? Arguably, if you call a SECURITY DEFINER function, then once > > you've decided that you trust the function owner, actual execution of the > > function should use the function owner's list of trusted roles not yours. > > With the GUC approach, it'd be necessary for SECURITY DEFINER functions > > to implement this with a "SET trusted_roles" clause, much as they now > > have to do with search_path. That's possible but it's again not very > > non-invasive, so we'd been speculating about automating this more. > > If we had, say, a catalog that provided the desired list of trusted roles > > for every role, then we could imagine implementing that context change > > automatically. Likewise, stuff like autovacuum or REINDEX would want > > to run with the table owner's list of trusted roles, but the GUC approach > > doesn't really provide enough infrastructure to know what to do there. > > I can't think of any other places we do transitive permissions, except > for role membership. I don't see the logic in adding such transitivity > to function/operator calls, or even a per-function GUC. I assume most > sites have a small number of extensions installed by a predefined group > of users, usually superusers. If there is a larger group, a group role > should be created and those people put in the role, and the group role > trusted. > I am wondering how this will interact with the inheritance of roles. For instance, if two users are members of the same role, and one creates a function the expectation would be that other users in the same role will not trust that function. However, do I trust functions that are owned by the roles that I am a member of? Or do I have to list any nested roles explicitly? If the former, I suppose we'd have to modify how alter function set owner works. It is currently allowed for roles that you are a member of (and would then create a security hole). However, not trusting functions owned by roles that I am a member of seems to also be a bit counterintuitive. Best, David
