Re: [PATCH] pgpassfile connection option - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [PATCH] pgpassfile connection option
Date
Msg-id CA+TgmoZxacvy7BA56iqd7sNGdZnVmGY8uUCJ7f-TfR7re5M2UQ@mail.gmail.com
Whole thread Raw
In response to Re: [PATCH] pgpassfile connection option  (Julian Markwort <julian.markwort@uni-muenster.de>)
Responses Re: [PATCH] pgpassfile connection option
List pgsql-hackers
On Thu, Sep 22, 2016 at 11:34 AM, Julian Markwort
<julian.markwort@uni-muenster.de> wrote:
> I haven't really thought about this as I had been asked to make this work as
> an additional option to the connection parameters...
> Now that I've looked at it - there is really only the benefit of saving the
> step of setting the PGPASSFILE environment variable.
> However, there might be cases in which setting an environment variable might
> not be the easiest option.

So, there are some security concerns here in my mind.  If a program
running under a particular user ID accepts a connection string from a
source that isn't fully trusted, the user has to accept the risk that
their .pgpass file will be used for authentication to whatever
database the program might try to connect.  However, they don't have
to accept the possibility that arbitrary local files readable by the
user ID will be used for authentication and/or disclosed; this patch
would force them to accept that risk.  That doesn't seem particularly
good.  If an adversary has enough control over my account that they
can set environment variables, it's game over: they win.  But if I
merely accept connection strings from them, I shouldn't have to worry
about anything worse than that I might be induced to connect to the
wrong thing.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Jesper Pedersen
Date:
Subject: Re: pageinspect: Hash index support
Next
From: Robert Haas
Date:
Subject: Re: Parallel tuplesort (for parallel B-Tree index creation)