On 2018-Jul-18, Marco van Eck wrote:
> Since .pgpass files contain plain-text passwords, I searched for an
> alternative.
> In the attached patch I've added the possibility to run a command to
> produce the content of the pgpass file, in exactly the same format. In this
> way I could use gpg or any other command to decrypt a pgpass file. It will
> prefer the .pgpass file and will not call the command.
>
> This would be my environment variable, to have no plain-text password:
> PGPASSCOMMAND="gpg -q -d pgpass.gpg"
>
> Other usages of the variable:
> PGPASSCOMMAND="cat pgpass"
> PGPASSCOMMAND="curl http://passwords/really-unsecure-pgpass"
> PGPASSCOMMAND="my-own-secure-pgpass-script"
>
> The submitted patch does it's job, though the command could throw errors.
>
> What do you think of this solution?
Seems to me that passing %-specifiers to the command would make it more
useful (%u for "user", "host" etc) -- your command could refuse to give
you a password for the superuser account for instance but grant one for
a read-only user. Or grant a password for the (hypothetical) pg_backup
user to the account doing the backups, but not to anyone else. Maybe if
the root/postgres user runs the program, all passwords are printed for
the instances in localhost/127.0.0.1.
That way, a client-side centralized security policy is just a SMOP.
Maybe there are reasons why this doesn't make sense and I'm not seeing
them -- if you do please point'em out.
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
