Skip site navigation (1) Skip section navigation (2)

Re: Insecurity of ODBC debug logging files

From: "Dave Page" <dpage(at)vale-housing(dot)co(dot)uk>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, <pgsql-odbc(at)postgresql(dot)org>
Subject: Re: Insecurity of ODBC debug logging files
Date: 2005-10-05 19:08:12
Message-ID: E7F85A1B5FF8D44C8A1AF6885BC9A0E4CC31E6@ratbert.vale-housing.co.uk (view raw or flat)
Thread:
Lists: pgsql-odbc
 

> -----Original Message-----
> From: pgsql-odbc-owner(at)postgresql(dot)org 
> [mailto:pgsql-odbc-owner(at)postgresql(dot)org] On Behalf Of Tom Lane
> Sent: 05 October 2005 18:50
> To: pgsql-odbc(at)postgresql(dot)org
> Subject: [ODBC] Insecurity of ODBC debug logging files
> 
> I have a gripe here:
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=154126
> about the fact that ODBC is willing to store passwords into debug log
> files that aren't secure.  Anyone want to do something about it?
> 
> Offhand it seems like simply omitting the password from the 
> log wouldn't
> be a bad idea.  

That was fixed almost 2.5 years ago by Hiroshi. I just check my own logs
and it does mask the passwords appropriately.

> But even then, a log file will frequently contain
> sensitive data (eg, credit card numbers appearing in INSERT 
> statements).
> Seems to me that there should also be some care taken to make the log
> file not world-readable.

I'll have a look at writing them with mode 600 on *nix. On Win9x and NT
based systems with FAT partitions there's nothing we can do of course.
I'd rather not make the filenames unpredicatable though as that'll make
it difficult for us to tell users how to track down the right debug log.

Regards, Dave.

Responses

pgsql-odbc by date

Next:From: Zlatko MatićDate: 2005-10-05 20:33:01
Subject: Re: [INTERFACES] [ODBC] Unbound text box, Text > 255 characters, MSAccess/PostgreSQL
Previous:From: Tom LaneDate: 2005-10-05 19:00:21
Subject: Re: Just as an FYI We are up solid now on pgsql libpq version

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group