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;

-- these would still be used to cover the "limited users" requirement


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.



Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to