Re: Proposal: two new role attributes and/or capabilities?

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.