On Sun, Feb 19, 2017 at 1:03 PM, Petr Jelinek <petr.jeli...@2ndquadrant.com> wrote:
> On 19/02/17 12:03, Magnus Hagander wrote: > > > > > > On Sun, Feb 19, 2017 at 2:01 AM, Michael Paquier > > <michael.paqu...@gmail.com <mailto:michael.paqu...@gmail.com>> wrote: > > > > On Sun, Feb 19, 2017 at 9:50 AM, Michael Paquier > > <michael.paqu...@gmail.com <mailto:michael.paqu...@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). -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
