Re: Have an encrypted pgpass file
От | Alvaro Herrera |
---|---|
Тема | Re: Have an encrypted pgpass file |
Дата | |
Msg-id | 20180718231601.5ld5zwe6qez5hhf5@alvherre.pgsql обсуждение исходный текст |
Ответ на | Have an encrypted pgpass file (Marco van Eck <marco.vaneck@gmail.com>) |
Ответы |
Re: Have an encrypted pgpass file
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: