Re: .pgpass and root: a problem - Mailing list pgsql-general

From Shaun Thomas
Subject Re: .pgpass and root: a problem
Date
Msg-id 51117930.5050306@optionshouse.com
Whole thread Raw
In response to Re: .pgpass and root: a problem  (Scott Marlowe <scott.marlowe@gmail.com>)
Responses Re: .pgpass and root: a problem  (Stephen Frost <sfrost@snowman.net>)
List 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 by date:

Previous
From: Scott Marlowe
Date:
Subject: Re: .pgpass and root: a problem
Next
From: Stephen Frost
Date:
Subject: Re: .pgpass and root: a problem