"David G. Johnston" <david.g.johnston@xxxxxxxxx> writes: > â??Would a scheme whereby you basically only get to SET ROLE one time work? > Basically the connection layer logs in and immediately SET SESSION > AUTHORIZATION AND SET ROLE [WITH SETTINGS?] to another role. For all > intents and purposes the session now looks as if that role was the one that > performed the login. However, that role is forbidden from changing its > identity. This removes attack vectors but also means that applications > cannot made use of finer grained grants without the main role inheriting > all of them. I can see this being an acceptable trade-off in some/many > uses. > When the session is returned to a pool it can either be kept around waiting > for another request by the same user or it would have to be closed and > reestablished should the connection need to be freed up for another user. Doesn't seem like this'd actually provide any useful functionality for a connection pooler. It still has to restrict any one underlying connection to be used by only one role. You've added more bookkeeping (because there's a state where a connection's role is unassigned) but no flexibility. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
