Re: [GENERAL] pgpass file type restrictions
| От | Desidero |
|---|---|
| Тема | Re: [GENERAL] pgpass file type restrictions |
| Дата | |
| Msg-id | CABvH9hUswpuxtghXO5aWi5C_kM38BeL-oun4K6WWkDEUCBi+dA@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: [GENERAL] pgpass file type restrictions (Andrew Dunstan <andrew.dunstan@2ndquadrant.com>) |
| Ответы |
Re: [GENERAL] pgpass file type restrictions
(Andrew Dunstan <andrew.dunstan@2ndquadrant.com>)
Re: [GENERAL] pgpass file type restrictions (Stephen Frost <sfrost@snowman.net>) |
| Список | pgsql-general |
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
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@2ndquadrant.com> wrote:
On 10/19/2017 02:12 AM, Tom Lane wrote:
> 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: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
В списке pgsql-general по дате отправления: