| 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: | Whole Thread | Raw Message | 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
| 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) |