From: | Magnus Hagander <magnus(at)hagander(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Steven Siebert <smsiebe(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: BUG #10680 - ldapbindpasswd leaks to postgresql log |
Date: | 2014-06-18 15:46:43 |
Message-ID: | CABUevEws_f9zgcO+RSwkzrHdJ7wBwFEBYr0-u8Cccm9M5OrTQA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Jun 18, 2014 at 4:50 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Steven Siebert <smsiebe(at)gmail(dot)com> writes:
> > Attached is a proposed patch for BUG #10680.
>
> > It's a simple fix to the problem of the ldapbindpasswd leaking in
> > clear text to the postgresql log. The patch simply removes the raw
> > pg_hba.conf line from the log message, but retains the log line number
> > to assist admins in troubleshooting.
>
> You haven't exactly explained why this is a problem. The proposed patch
> would impede diagnosing of many other problems, so it's not going to get
> committed without a thoroughly compelling rationale.
>
Yes, properly logging that was intentional, in commit
7f49a67f954db3e92fd96963169fb8302959576e.
Hint: "I don't store my postmaster log securely" is not compelling.
> We've been over that ground before; there are far too many reasons
> why access to the postmaster log is a potential security hazard
> to justify concluding that this particular one is worse.
>
Yeah, and the password is already in cleartext in a file next to it.
If we actually feel the need to get rid of it, we should do a better job.
Such as actively blanking it out with something else. Since we know the
password (we parsed it out), it shouldn't be impossible to actually blank
out *just the password*, without ruining all the other diagnostics usage of
it.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2014-06-18 16:13:00 | Re: Atomics hardware support table & supported architectures |
Previous Message | Christoph Berg | 2014-06-18 15:41:06 | Is analyze_new_cluster.sh still useful? |