Sorry Tom (and others), I didn't notice my change affected libpq. Though I would really like the possibility to have an encrypted way of presenting the pgpassfile. Would it be more secure if the script / command is passed as a compile option to libpg and the variable only contains the filename of the encrypted file or only the arguments to pass to the command and use the original pgpassfile to decrypt. As always the security of the library / command in the hands of the person who compiles it.
So assume the library is compiled with PGPASSDECRYPTCOMMAND=/usr/bin/gpg
PGPASSFILE=pgpass.gpg
PGPASSARGUMENTS="-q -d"
In the end libpq would call: '/usr/bin/gpg -q -d pgpass.gpg'
The only thing I'm wondering, is it flexible enough for use cases different than mine? Or should I make a static variable for it so the user of the libpq can define it if they want to use the feature, and if not defined ignore the feature? I can make a new patch, if this is the direction we want to go.
Best regards,
Marco van Eck
Isaac Morland <isaac.morland@gmail.com> writes:
>>> It would also provide a *very* fertile source of shell-script-injection
>>> vulnerabilities. (Whaddya mean, you tried to use a user name with a
>>> quote mark in it?)
> If I understand the proposal correctly, the pgpass program would run on the
> client, invoked by libpq when a password is needed for a connection. So the
> risk relates to strange things happening on the client when the client
> attempts to connect as a strangely-named user or to a strangely-named
> database or host, not to being able to break into the server.
Yeah. The most obvious scenario for trouble is that somebody enters
a crafted user name on a website, and that results in bad things happening
on an application-server machine that tried to pass that user name to
a database server. The DB server itself isn't compromised, but the app
server could be.
If we were putting this sort of feature into psql, it wouldn't be such
a risk, but if it's in libpq then I fear it is. libpq underlies a lot
of client-side code.
regards, tom lane
