In any event, is the use case problematic enough that it would prevent the proposed changes from being implemented? I could submit a patch to postgres hackers if necessary, but if it's undesirable I can figure out something else.
Regards,
Matt
On Thu, Oct 19, 2017 at 7:22 AM Andrew Dunstan <andrew.dunstan@xxxxxxxxxxxxxxx> wrote:
On 10/19/2017 02:12 AM, Tom Lane wrote:
> Desidero <desidero@xxxxxxxxx> writes:
>> I’m running into problems with the restriction on pgpass file types. When
>> attempting to use something like an anonymous pipe for a passfile, psql
>> throws an error stating that it only accepts plain files.
>> ...
>> Does anyone know why it’s set up to avoid using things like anonymous pipes
>> (or anything but "plain files")?
> A bit of digging in the git history says that the check was added here:
>
> commit 453d74b99c9ba6e5e75d214b0d7bec13553ded89
> Author: Bruce Momjian <bruce@xxxxxxxxxx>
> Date: Fri Jun 10 03:02:30 2005 +0000
>
> Add the "PGPASSFILE" environment variable to specify to the password
> file.
>
> Andrew Dunstan
>
> and poking around in the mailing list archives from that time finds
> what seems to be the originating thread:
>
> https://www.postgresql.org/message-id/flat/4123BF8C.5000909%40pse-consulting.de
>
> There's no real discussion there of the check for plain-file-ness.
> My first guess would have been that the idea was to guard against
> symlink attacks; but then surely the stat call needed to have been
> changed to lstat? So I'm not quite sure of the reasoning. Perhaps
> Andrew remembers.
That was written 13 years ago. I'm afraid my memory isn't that good.
>
>> If it matters,
>> I'm trying to use that so I can pass a decrypted pgpassfile into postgres
>> since my company is not allowed to have unencrypted credentials on disk
>> (yes, I know that it's kind of silly to add one layer of abstraction, but
>> it's an industry rule we can't avoid).
> I cannot get excited about that proposed use-case, though. How is a pipe
> any more secure than a plain file with the same permissions?
If it's not allowed to reside on disk, put it on a RAM disk?
>
> My thought is that you shouldn't be depending on passwords at all, but
> on SSL credentials or Kerberos auth, both of which libpq supports fine.
>
Yeah, we need to be convincing people with high security needs to get
out of the password game. It's a losing battle.
cheers
andrew
--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
