Re: Have an encrypted pgpass file

On Wed, Jul 18, 2018 at 11:19 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Sorry, I don't buy that line of argument.  The *only* reason for this
> feature to exist is if it allows ready creation of security solutions
> that are actually more secure than a non-world-readable .pgpass file.
> That's a much higher bar than many people realize to begin with ...
> and if it comes along with huge risk of security foot-guns, I do not
> think that it's going to be a net advance.

I don't think I agree with this objection.  First, not doing anything
won't be a net advance, either.  Second, your objection seems akin to
saying "we're not going to let you drive because you might crash the
car".  There are *some* people who should not be allowed to get behind
the wheel, but your proposal seems analogous to banning *everyone*
from driving on the theory that car crashes are bad.  I think that's
an overreaction.  I agree that there's probably a risk, but why can't
we just document best practices?  Really, I'm not sure that it's right
to suppose that you're calling a shell script specifically.  If it's a
Perl, Python, Ruby, etc. script the risk is probably much less --
you're going to take $ARGV[1] or the equivalent and shove it in a
string variable, and after that it's not really any more or less risky
than any other string variable you've got.  You could of course
perform an ill-considered interpolation into a shell command, but
that's true of any string that originates from a user in any
situation, and if you're a somewhat-knowledgeable programmer you
probably won't.  Generally you have to do *extra* work to make things
safe in the shell, whereas in a scripting language you just have to
not screw up.  foo($thingy) is safe in Perl; foo $thingy is unsafe in
the shell.  Of course mistakes are possible and we can avoid all the
mistakes by not providing the feature, but to me, that doesn't seem
like the way to go.

> One reason I'd like to see a concrete use-case (or several concrete
> use-cases) is that we might then find some design that's less prone
> to such mistakes than "here, run this shell script" is going to be.

I think that the most common use case is likely to be to get the data
from a local or remote keyserver.  For example, when I'm logged in, my
keychain is available to provide passwords; when I log out, those
passwords aren't accessible any more.  Or, when the server is in the
datacenter where it's supposed to be located, it can pull the data
from some other machine in that data center whose job it is provide
said data; when the server is physically stolen from the datacenter
and taken to some other location, the other machine isn't there and
necessary credentials are no longer available (or even if the other
machine *is* there, it probably requires a manually-entered password
to start the key service, which the thief may not have).

> I'm vaguely imagining exec'ing a program directly without a layer
> of shell quoting/evaluation in between; but not sure how far that
> gets us.

It's not a bad thought, although it might not help that much if it
causes somebody who would have written PGPASSCOMMAND="this that" to
instead set PGPASSCOMMAND="thisthat.sh" where that file contains

#!/bin/bash
this that

...which seems like a likely outcome.

> Another question that ought to be asked somewhere along here is
> "how well does this work on Windows?" ...

True.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company