Thread: R: Re: R: Re: create subscription, connection string, password inlog not hide
R: Re: R: Re: create subscription, connection string, password inlog not hide
From
"ferraresso@tin.it"
Date:
I keep the CC, sorry, this is my first post here.
I used to never write the clear password on any production server.
So I am looking for the simplest way to keep safe.
I don't know about the "pg_subscription" where there is the connection string.
The connection with SSL will add complexity that is not required on local databases.
The best solution for my situation will be to create a role dedicated to this job, where I can add some limits: access to one database, access from one ip.
Thank you
Loris
I used to never write the clear password on any production server.
So I am looking for the simplest way to keep safe.
I don't know about the "pg_subscription" where there is the connection string.
The connection with SSL will add complexity that is not required on local databases.
The best solution for my situation will be to create a role dedicated to this job, where I can add some limits: access to one database, access from one ip.
Thank you
Loris
----Messaggio originale----
Da: laurenz.albe@cybertec.at
Data: 22-gen-2018 19.51
A: "ferraresso@tin.it"<ferraresso@tin.it>
Cc: <pgsql-novice@lists.postgresql.org>
Ogg: Re: R: Re: create subscription, connection string, password in log not hide
Please keep the list in CC.
ferraresso@tin.it wrote:
> - using trust is not an options on a production system;
It isn't if you are very security concious.
I normally use trust authentication, limited to one IP address,
a user and the database "replication", on production systems.
> - disable the log can be a solution, but:
> the password will still be transmitted trought the net in clear form;
> the log can be useful when looking for problem. Disabling the log is a thing that I prefer not to do;
> I have to remember to do the disable of log every time I create the replication, well,
> I can do, but meybe was better to have that inside the same command, like CREATE USER.
On the other hand, if you are very security conscious, you will
use SSL encrypted database connections.
True, it is annoying that the password is transmitted and might
be logged if you are not careful, but things are even worse:
The connection string is stored in "pg_subscription", and any
superuser can SELECT it from that table.
One option for you might be to use a password file on the server
and not put the password into the connection string.
You have to have the password *somewhere* for the standby to connect
to the primary.
Yours,
Laurenz Albe