Re: Best way to "mask" password in DBLINK - Mailing list pgsql-general

From Tommy Gildseth
Subject Re: Best way to "mask" password in DBLINK
Date
Msg-id 4A827952.9020801@usit.uio.no
Whole thread Raw
In response to Re: Best way to "mask" password in DBLINK  ("Ow Mun Heng" <ow.mun.heng@wdc.com>)
List pgsql-general
Ow Mun Heng wrote:
>
> -----Original Message-----
> From: Magnus Hagander [mailto:magnus@hagander.net]
> On Wed, Aug 12, 2009 at 09:30, Ow Mun Heng<ow.mun.heng@wdc.com> wrote:
>>> From: Tommy Gildseth [mailto:tommy.gildseth@usit.uio.no]
>>>
>>> Ow Mun Heng wrote:
>>>>> I'm starting to use DBLink / DBI-Link and one of the "bad" things is
>>>> that
>>>>> the password is out in the clear.
>>>>> What can I do to prevent it from being such? How do I protect it from
>>>>> 'innocent' users?
>>>> If I'm not mistaken, it's possible to put your password in the .pgpass
>>>> file in the postgres-users home folder, on the server where the postgres
>>>> cluster is running.
>>> Isn't that how one connects using the CLI? Eg: via psql?
>
>> You need to put it in the .pgpass file of the postgres user - the one
>> that runs the server. .pgpass is dealt with by libpq, and DBLink and
>> DBI-Link both use libpq to connect to the remote server.
>
> The View is owned by the user "operator" not postgres
> Does it make a difference?
>
> My understanding of your words are that it _does_ make a difference and If I
> put it into the .pgpass of the postgres user then all is fine.

No, it doesn't matter which role owns the database object. The system
user trying to connect to the remote cluster via dblink, is the user
which owns the postgres process, ie. normally the postgres system user.
libpq will therefor look for the .pgpass file in the postgres system
users home folder, irrespective of which role owns the database, or
which role is used to connect to the database etc.

--
Tommy Gildseth

pgsql-general by date:

Previous
From: "Ow Mun Heng"
Date:
Subject: Re: Best way to "mask" password in DBLINK
Next
From: Magnus Hagander
Date:
Subject: Re: PQoidValue - isn't it for...?