Re: elog() patch - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: elog() patch
Date
Msg-id 200203050643.g256hha25930@candle.pha.pa.us
Whole thread Raw
In response to Re: elog() patch  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: elog() patch  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Can you take care of the echo of entered password too,
> 
> I'm unconvinced that that's wrong, and will not change it without
> more discussion.  (1) The reason it was put in was to allow debugging
> of "that's the wrong password" mistakes.  (2) The postmaster log
> inherently contains a great deal of sensitive information, so anyone
> who runs with it world-readable has a problem already.  (3) The password
> is not emitted unless the message level is a lot lower than anyone would
> routinely use.  (4) If you're using the recommended MD5 encryption
> approach, then what's logged is encrypted; it seems no more dangerous
> than having encrypted passwords in pg_shadow.

OK, I have thought about how we display invalid passwords in the server
logs.  This isn't an issue if the password is the same as stored in
pg_shadow.  However, if the invalid password was incorrect because it
was their Unix password or a password on another machine, I think we do
have an issue storing it in the server logs.  I can't think of any unix
utility that stores invalid passwords in the log, no matter what the
debugging level, and I don't think we should be doing it either.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Storage Location Patch Proposal for V7.3
Next
From: Tom Lane
Date:
Subject: Re: elog() patch