On Wed, Jul 18, 2018 at 11:19 PM, Tom Lane <t...@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
