Desidero <desidero@gmail.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@momjian.us> Date: Fri Jun 10
03:02:302005 +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
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general