Re: One Role, Two Passwords
От | Daniel Farina |
---|---|
Тема | Re: One Role, Two Passwords |
Дата | |
Msg-id | AANLkTim-+Ym9p31zUTDzF-vZZRLQAkwDw2ZLjj=o8wZ1@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: One Role, Two Passwords (Josh Berkus <josh@agliodbs.com>) |
Ответы |
Re: One Role, Two Passwords
|
Список | pgsql-hackers |
On Thu, Jan 20, 2011 at 5:32 PM, Josh Berkus <josh@agliodbs.com> wrote: > >> * Eventual Retirement of old credentials without having to issue ALTER >> statements (or really statements of any kind...) against application >> schema objects. > > OK, that's a different goal. You want to be able to expire passwords > with an overlap period. That's quite different from wanting an > indefinfite number of passwords per role. Correct; although I don't see a reason to strictly abide by two. Still, it would get most jobs done. > Mind you, the main way to do this right now ... and where you're going > to get pushback ... is using LDAP, ActiveDirectory or similar. At a > certain point we have to draw the line and say "PostgreSQL is not an > authtenication server". I don't know exactly where that line is, but > recognize that you're arguing about where to draw it. Quite correct, as I conceded to Andrew initially. PAM may also be an option to work around. The problem is that running a reliable, centralized LDAP service is not justifiable as compared to role mangling on a per-node level, and the role mangling seems has some shortcomings that are negotiable with gritted teeth. A goldilocks case so far of "too hot" and "too cold" I think is exhibited here. I do not think the problem unreasonable and it will become increasingly common on larger and more diverse Postgres deployments, especially on hosted (do I need to say cloud?) infrastructure which cannot make as many consistency guarantees about processes starting all over the place. For that reason I have brought it to -hackers. -- fdr
В списке pgsql-hackers по дате отправления: