Re: Provide list of subscriptions and publications in psql's completion

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)com>
Cc: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Provide list of subscriptions and publications in psql's completion
Date: 2017-02-19 12:33:20
Message-ID: CABUevEz5SP=k8bT8e0jMWRXHkkvn-rzHXKiwXDJcsVMH8-k4rw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Feb 19, 2017 at 1:03 PM, Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)com>
wrote:

> On 19/02/17 12:03, Magnus Hagander wrote:
> >
> >
> > On Sun, Feb 19, 2017 at 2:01 AM, Michael Paquier
> > <michael(dot)paquier(at)gmail(dot)com <mailto:michael(dot)paquier(at)gmail(dot)com>> wrote:
> >
> > On Sun, Feb 19, 2017 at 9:50 AM, Michael Paquier
> > <michael(dot)paquier(at)gmail(dot)com <mailto:michael(dot)paquier(at)gmail(dot)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).

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2017-02-19 12:35:53 Re: Instability in select_parallel regression test
Previous Message Robert Haas 2017-02-19 12:24:27 Re: Instability in select_parallel regression test