Re: pgpass file type restrictions

Desidero <desidero(at)gmail(dot)com> 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(at)momjian(dot)us>
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.

> 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?

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.

regards, tom lane