On 12/23/2014 07:01 PM, David G Johnston wrote:
> 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
Yes, and exclusively for this purpose.
> instead of
>
> GRANT victim1 TO bouncer;
> GRANT victim2 TO bouncer;
> etc...
>
> -- these would still be used to cover the "limited users" requirement
> ?
Yup.
> Seems contrary to the principle of least privilege goal...
We still wouldn't grant any CREATE DATABASE, CREATE TABLESPACE,
CREATE/LOAD EXTENSION, CREATE LANGUAGE, etc (and the ability to create/use/manipulate data within the database
will still be constrained by the impersonated login)
> I'd rather there be better, more user friendly, SQL-based APIs to the
> permissions system that would facilitate performing and reviewing grants.
+1. All suggestions welcome.
> 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
Indeed, I had thought about this too.
> - and also make SUPERUSER roles unimpersonable by rule.
Yes, of course. Otherwise, the distinction would not have any sense.
Thanks,
J.L.
