[GENERAL] pgpass file type restrictions

[Desidero]

Hello,



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. 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 know that we can also just avoid
using psql, but there are benefits to using it for simple scripts, so if we
can make this work fairly easily we'd like to do that.



I looked around to see if I could figure out why that restriction was put
there in the first place, but the only reference I found was this entry in
the 8.2.6 release notes which I wasn’t able to trace back to anything in
particular:

Fix libpq crash when PGPASSFILE refers to a file that is not a plain file
(Martin Pitt)



I was also unable to find anything useful in the source code. There were no
comments around this snippet indicating why it was limited to plain files
(it was implemented this way back in 2005!):

https://github.com/postgres/postgres/blame/d3a0c8dce9380e77734e41becd9aa3
5618030352/src/interfaces/libpq/fe-connect.c#L3138

if (!S_ISREG(stat_buf.st_mode))

{

fprintf(stderr,


libpq_gettext("WARNING: Password file %s is not a plain file.\n"),

pgpassfile);

free(pgpassfile);

return NULL;

}



Does anyone know why it’s set up to avoid using things like anonymous pipes
(or anything but "plain files")?



Regards,

Matt

Re: [GENERAL] pgpass file type restrictions

[Desidero]

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.duns...@2ndquadrant.com> wrote:

>
>
> On 10/19/2017 02:12 AM, Tom Lane wrote:
> > Desidero  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 
> > Date:   Fri Jun 10 03:02:30 2005 +
> >
> > 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 Dunstanhttps://www.2ndQuadrant.com
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>
>
>