Re: BUG #18379: LDAP bind password exposed

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: coelho(dot)viniciusdf(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #18379: LDAP bind password exposed
Date: 2024-03-06 19:52:28
Message-ID: 295987.1709754748@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Stephen Frost <sfrost(at)snowman(dot)net> writes:
> While I agree that users should take steps to secure their log files,
> I'd argue that it's best practice to avoid dumping sensitive data into
> log files, which it seems like it would be in this case. I'm not
> suggesting that this is bug-worthy or that we should go to excessive
> lengths to try and prevent every such case, but if someone showed up
> with a reasonable patch to replace the sensitive information in a pg_hba
> line with ****, I would be on the side of supporting that.

I dunno, I think it would mostly serve to set false expectations.
We've repeatedly rejected requests to scrub the log of passwords
found in CREATE/ALTER USER commands, for example. I think some
of the same issues that led to that conclusion would apply here,
notably that a syntax error could lead to failing to recognize
at all that some substring is a password. (A visibly erroneous
pg_hba line would not get quoted in the specific context the OP
complains of, but I'm pretty sure we'd print it while logging
the configuration reload failure.)

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2024-03-06 20:09:09 Re: Record returning function accept not matched columns declaration
Previous Message Noah Misch 2024-03-06 18:42:28 Re: FSM Corruption (was: Could not read block at end of the relation)