José Luis Tallón-2 wrote > On 12/23/2014 05:29 PM, Stephen Frost wrote: >> * José Luis Tallón (
> jltallon@ > ) wrote: >>> * IMPERSONATE --- Ability to do "SET AUTHORIZATION TO some_role;" >>> and "RESET AUTHORIZATION" >>> This might be further refined to provide a way to say "This role >>> is authorized to impersonate role1 but no other" >>> Rationale: for use by connection poolers (esp. pgBouncer), where >>> the role used for connection would only have the LOGIN and >>> IMPERSONATE privileges. The remaining operations would be authorized >>> against the supplanted role (i.e. ability to create tables/indexes >>> or views, perform DML and/or DDL, etc) >>> AFAIK, a superuser role is needed for this purpose currently. >> No.. You can have 'no-inherit' roles which you can use for exactly this >> purpose. The initial login role can have no rights on the database, >> except to SET ROLE to other roles which have been granted to it. > > Hmm.... the current documentation states that: "The specified role_name > must be a role that the current session user is a member of". > I can see use cases where making the login role a member of every other > used role quickly becomes a burden, and that's the main driver for this > feature (I'm thinking about multiple app servers running several > applications each, minimum two roles per application) So you want to say: GRANT IMPERSONATE TO bouncer; --covers the "ALL" requirement instead of GRANT victim1 TO bouncer; GRANT victim2 TO bouncer; etc... -- these would still be used to cover the "limited users" requirement ? Seems contrary to the principle of least privilege goal... I'd rather there be better, more user friendly, SQL-based APIs to the permissions system that would facilitate performing and reviewing grants. If something like IMPERSONATE was added I would strongly suggest a corresponding "[NO]IMPERSONATE" for CREATE USER so that the admin can make specific roles unimpersonable - and also make SUPERUSER roles unimpersonable by rule. David J. -- View this message in context: http://postgresql.nabble.com/Proposal-two-new-role-attributes-and-or-capabilities-tp5831859p5831868.html Sent from the PostgreSQL - hackers mailing list archive at Nabble.com. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers