Re: BUG #16550: Problem with pg_service.conf

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Michał Lis <fcs1(at)poczta(dot)onet(dot)pl>
Cc: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Christophe Pettus <xof(at)thebuild(dot)com>, pgsql-bugs <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Subject: Re: BUG #16550: Problem with pg_service.conf
Date: 2020-07-23 16:12:28
Message-ID: CAKFQuwYLQF843NuBo6kncJ1Z1tLjWxM7Bh14t6V5s0pYxiMkjw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Thu, Jul 23, 2020 at 8:26 AM David G. Johnston <
david(dot)g(dot)johnston(at)gmail(dot)com> wrote:

> On Thu, Jul 23, 2020 at 7:26 AM Michał Lis <fcs1(at)poczta(dot)onet(dot)pl> wrote:
>
>>
>> I need it all to hide connection properties in QGIS and make QGIS project
>> independent from servers used in different places.
>>
>
> That isn't a sufficient level of detail for someone else to describe a
> solution (if you provide more please start a new thread on -general).
>

To seed some thoughts on how that -general discussion could go:

At a fundamental level if the database is physically accessible to an
uncontrolled machine there is no perfect solution to preventing the
administrator of that machine from obtaining the credentials being used by
the application and using them directly. The decision is what level of
effort do you want to impose on the administrator to do that (or user,
though that is even simpler). If it must be out of the realm of
possibility then the software is improperly written given the constraints -
it should not utilize direct database connectivity and instead speak with a
fully controlled intermediary server in some other protocol and that
intermediary server then talks with the database.

Assuming that rewriting the software is not an option the discussion that
needs to happen revolves around which are the available/reasonable options
for getting unencrypted credentials into the application's memory space so
that it may use them in a very private way. At the same time, what are the
use cases where tools like pgAdmin would be required and used responsibly
versus where the same tool is being used undesirably.

David J.

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2020-07-23 19:38:43 Re: BUG #16476: pgp_sym_encrypt_bytea with compress-level=6 : Wrong key or corrupt data
Previous Message David G. Johnston 2020-07-23 15:26:41 Re: BUG #16550: Problem with pg_service.conf