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
