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

From Scott Marlowe
Subject Re: .pgpass and root: a problem
Date
Msg-id CAOR=d=1cg7o87GfgKc4G+HgsjTQ4R3F0QRhLv4q55qNPePnMJw@mail.gmail.com
Whole thread Raw
In response to Re: .pgpass and root: a problem  (Shaun Thomas <sthomas@optionshouse.com>)
Responses Re: .pgpass and root: a problem  (Shaun Thomas <sthomas@optionshouse.com>)
List pgsql-general
On Tue, Feb 5, 2013 at 12:07 PM, Shaun Thomas <sthomas@optionshouse.com> wrote:
> On 02/05/2013 12:44 PM, Scott Marlowe wrote:
>
>> Stop.  If you want secure setups you don't hand out root access to
>> lots of people.  Trying to then make it secure is like closing the
>> barn door after the horse has left.
>
>
> I guess you missed the part where I said I thought we should lock root down
> better. I can certainly influence that policy, but I can't enforce it. But
> there's also this addendum I added:

I don't miss much. I didn't miss that.  You specifically said:

"I agree that we should probably have our root access much more locked
down than it is, but it's still a valid problem."

Probably?  Definitely.

"I don't think I'd even want a restricted set of root users able to
see my LDAP password in plain text."

Why are you using LDAP and passing passwords for access to insecure
systems? If you're passing PASSWORDS to an insecure system then you
have a real problem.  At least move to a token based system like
kerberos where a lost token represents a short period of someone
having the same access as you but not getting your password.  Or just
run your pg databases in trust or some simple md5 and use a different
password.

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.

pgsql-general by date:

Previous
From: Stephen Frost
Date:
Subject: Re: .pgpass and root: a problem
Next
From: Shaun Thomas
Date:
Subject: Re: .pgpass and root: a problem