Re: [HACKERS] Provide list of subscriptions and publications inpsql's completion - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: [HACKERS] Provide list of subscriptions and publications inpsql's completion
Date
Msg-id CABUevEz5SP=k8bT8e0jMWRXHkkvn-rzHXKiwXDJcsVMH8-k4rw@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Provide list of subscriptions and publications inpsql's completion  (Petr Jelinek <petr.jelinek@2ndquadrant.com>)
List pgsql-hackers


On Sun, Feb 19, 2017 at 1:03 PM, Petr Jelinek <petr.jelinek@2ndquadrant.com> wrote:
On 19/02/17 12:03, Magnus Hagander wrote:
>
>
> On Sun, Feb 19, 2017 at 2:01 AM, Michael Paquier
> <michael.paquier@gmail.com <mailto:michael.paquier@gmail.com>> wrote:
>
>     On Sun, Feb 19, 2017 at 9:50 AM, Michael Paquier
>     <michael.paquier@gmail.com <mailto:michael.paquier@gmail.com>> wrote:
>     > I have been poking at it, and yeah... I missed the fact that
>     > pg_subcription is not a view. I thought that check_conninfo was being
>     > called in this context only..
>
>     Still, storing plain passwords in system catalogs is a practice that
>     should be discouraged as base backup data can go over a network as
>     well... At least adding a note or a warning in the documentation would
>     be nice about the fact that any kind of security-sensitive data should
>     be avoided here.
>
>
> Isn't that moving the goalposts quite a bit? We already allow passwords
> in CREATE USER MAPPING without any warnings against it (in fact, we
> suggest that's what you should do), which is a similar situation. Same
> goes for dblink.
>
> If password auth is used, we have to store the password in plaintext
> equivalent somewhere. Meaning it's by definition going to be exposed to
> superusers and replication downstreams. Or are you suggesting a scheme
> whereby you have to enter all your subscription passwords in a prompt of
> some kind when starting the postmaster, to avoid it?
>

The subscriptions will happily use .pgpass for example so it's not like
users are forced to put password to catalog (well barring some DBaaS
solutions). But I guess it would not hurt to give extra notice in docs
about dangers of the various catalogs storing passwords.


I certainly wouldn't object to doing that, but if we do we should consistently do it in the other places that have work the same way (like user mappings). 

--

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [HACKERS] Instability in select_parallel regression test
Next
From: Robert Haas
Date:
Subject: Re: [HACKERS] Instability in select_parallel regression test