Re: RFC: Non-user-resettable SET SESSION AUTHORISATION
От | Robert Haas |
---|---|
Тема | Re: RFC: Non-user-resettable SET SESSION AUTHORISATION |
Дата | |
Msg-id | CA+TgmobCJXu2h-gi_P4yaL7SZLQfvDWp68o5Q0Rndj=S7SG--A@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: RFC: Non-user-resettable SET SESSION AUTHORISATION (Jim Nasby <Jim.Nasby@BlueTreble.com>) |
Ответы |
Re: RFC: Non-user-resettable SET SESSION AUTHORISATION
|
Список | pgsql-hackers |
On Wed, May 20, 2015 at 8:22 PM, Jim Nasby <Jim.Nasby@bluetreble.com> wrote: >> It might be a good idea to do something like this, but it's >> significantly more complicated than a protocol-level SET SESSION >> AUTHORIZATION. Right now, you can never go backwards from an >> authenticated state to an unauthenticated state, and there may be code >> in the backend that relies on that in subtle ways. The initial >> bootstrap sequence is pretty complicated, and I'm pretty sure that any >> naive attempt to redo that stuff is going to have unpleasant, probably >> security-relevant bugs. > > What about the middle-ground of not doing de-auth right now? That eliminates > your concerns but still allows getting rid of ugly things like copies of the > password file (FWIW, my understanding is pgBouncer was meant more to run on > the database server where you'd just point it at the native password file). Uh, I don't have a clue what you mean when you say "the middle ground of not doing de-auth right now". -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: