Re: .pgpass and root: a problem
От | Shaun Thomas |
---|---|
Тема | Re: .pgpass and root: a problem |
Дата | |
Msg-id | 51117930.5050306@optionshouse.com обсуждение исходный текст |
Ответ на | Re: .pgpass and root: a problem (Scott Marlowe <scott.marlowe@gmail.com>) |
Ответы |
Re: .pgpass and root: a problem
|
Список | pgsql-general |
On 02/05/2013 02:58 PM, Scott Marlowe wrote: > Why are you using LDAP and passing passwords for access to insecure > systems? We're trying not to. That's kind of my point. Now, I'd love to spend another few days learning yet another auth mechanism (kerberos) but I was trying to avoid it. As it stands now, I followed a couple "step by step" things I found via google, and all I get is this when trying to use kerberos: psql: GSSAPI continuation error: Unspecified GSS failure. Minor code may provide more information GSSAPI continuation error: Server not found in Kerberos database Not extremely useful. Here's what I don't get... If I'm my own user, and I call "kinit", it sets up my kerberos cache, having obtained it from our AD server. Presumably, that means kerberos is a service that can forward requests to another server (AD) if it gets a request that isn't in its local cache. If it gets a response, that response is added to the local cache for the next request. If not, I'm missing the benefit of kerberos. IMO, telling PG to use gss/kerberos should be as simple as turning it on, so whatever installed handling mechanism is consulted, ala PAM. Clearly I'm missing something. I'm going to read some docs to figure out the stack, but I've never seen this particular thing before. > If you can't trust the machines on the other end, no amount of > password mangling is going to help hide the passwords. You have to > move to some other form of authentication or use passwords you don't > care about. Which was why until now, we've been using passwords that are only valid in the database, and superusers can only connect via local accounts via peer auth. And our prod systems *are* locked down much better than the dev ones, but the dev ones are the concern. People are bound to play loosey-goosey with the dev servers, and I don't want that to turn into some ridiculous exploit. It's obvious I should abandon LDAP. Fine. I tried PAM auth (which is configured to forward to AD), and that works graet, but has the same problem. If the user is presented with a PW prompt more than once in a row, something has failed. -- Shaun Thomas OptionsHouse | 141 W. Jackson Blvd. | Suite 500 | Chicago IL, 60604 312-676-8870 sthomas@optionshouse.com ______________________________________________ See http://www.peak6.com/email_disclaimer/ for terms and conditions related to this email
В списке pgsql-general по дате отправления: