Re: pgpass file type restrictions

I agree that it would be better for us to use something other than LDAP,
but unfortunately it's difficult to convince the powers that be that we
can/should use something else that they are not yet prepared to properly
manage/audit. We are working towards it, but we're not there yet. It's not
really an exuse, but until the industry password policies are modified to
outright ban passwords, many businesses will probably be in this position.

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(dot)dunstan(at)2ndquadrant(dot)com> wrote:

>
>
> On 10/19/2017 02:12 AM, Tom Lane wrote:
> > 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.
>
>
>
> 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
>
>
>