> -----Original Message-----
> From: David Ciarniello [SMTP:brainlost@rocketmail.com]
> Sent: Friday, July 06, 2001 11:56 AM
> To: Henshall, Stuart - WCP
> Cc: pgsql-odbc@postgresql.org
> Subject: R: ODBC 7.0006 bugs
>
>
Makes me glad I havn't used the parse option (what is it for?)
> > 3) I can see you're point. However I tend not to use DSN's but
> > rather connection strings so its helpful to be able to turn on logging
> with
> > out editing the program.
>
> Can't we move all settings on a datasource basis continuing to support
> all parametrs on connection strings ?
>
I was meaning so that I didn't have to change my connect string at
all. Maybe having all the options available as driver defaults which are
only overwritten if they are also in the datasource string. I must admit I
don't really know about the drivers internals so have no idea how tricky
that would be.
> > 5) I disagree. If I'm having problems connecting I want to see all
> > the options in the connection string. Don't log when you're not
> debugging,
> > it slows everything down.
>
> You can find the authentication response into the backend logs (like the
> (in)famous "password authentication failed for user admin")
>
yes, but it doesn't give the ODBC side of the story.
> Instead somebody could activate the logger without my authorization
> (consider a pc that shares the hard drive, just put the right reg file
> into
> the startup folder and wait for the next reboot - considering win9x
> stability you don't have to wait too much :-)) - so that the log can be
> produced... you can grab the password from a network environment even
> without ever seeing that pc).
> I think it's a security risk.
>
True. Howeversomeone could just make a little alteration to
the source, recompile the ODBC driver then drop it into \windows\system.
Having sensitive areas of the disk shared is inherently unsafe. Or someone
could write a wrapper DLL that just passed everything along while grabbing
the PWD. Or drop a Trojan into your startup to expose your PC. I suppose
these would be trickier, but not ridiculously so. Maybe have two driver
builds. A production model that disables logging (plus anything else deemed
a risk) and a developer version that allows it to be enabled. I really must
get MSVC so I can fiddle with the driver like this.
- Stuart
