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.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
