Re: Patch for ODBC driver (look for odbc.ini in more than one

From: Igor Kovalenko <Igor(dot)Kovalenko(at)motorola(dot)com>
To: Ross Thomas <ross(at)grinfinity(dot)com>
Cc: pgsql-patches(at)postgresql(dot)org
Subject: Re: Patch for ODBC driver (look for odbc.ini in more than one
Date: 2001-12-10 20:23:41
Message-ID: 3C1519CD.CC38375E@motorola.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

I ran into this issue too. Not sure whether it is useful to check 4
locations, but current code is certainly broken. It does check for
odbcinst.ini in ~user and default location, but only ~user for odbc.ini.
First, that is inconsistent, then it is not very useful when you try to
use ODBC from something like PHP, which often will run as 'nobody'
(which often means no homedir).
Default location certainly should be searched and that would not require
big changes. Looking at the code I actually think original coder meant
to do that but overlooked that code will only work for odbcinst.ini.

As for security implications, since code aready does check ~user, I
would not think that adding default place would make it any less secure.

I don't really get it why do you want to add another configure option at
all, it is confusing enough already. I would think that odbcinst.ini and
[default] odbc.ini normally should be in the same place.

regards,
- igor

Ross Thomas wrote:
>
> Since most ODBC drivers and driver managers look for odbc.ini in several
> locations on UNIX systems, it would seem sensible to have the PostgreSQL
> driver do the same thing. (This idea occurred to me after five hours of
> trying to figure out what libpsqlodbc didn't like about my /etc/odbc.ini,
> but that's another story.)
>
> iODBC, for example, does the following:
>
> 1) Checks $ODBCINI
> 2) Checks $HOME/.odbc.ini
> 3) Checks ~/.odbc.ini (where ~ is obtained from struct passwd)
> 4) Checks system-wide odbc.ini (in /etc by default)
>
> This is essentially backwards-compatible with the old behaviour, unless
> $ODBCINI is defined (in which case, arguably, the DBA knows what he's doing
> anyway...). It resembles the Windows approach of allowing both user and
> system data sources.
>
> The attached patch implements this search path in 7.1.3's
> GetPrivateProfileString(). It patches the following files:
>
> configure.in
> src/Makefile.global.in
> src/interfaces/odbc/GNUmakefile
> src/interfaces/odbc/dlg_specific.h
> src/interfaces/odbc/gpps.c
>
> It works for me (GNU/Linux i686). Possible issues include:
>
> - Security. Since this library could (unwisely) be called from a setuid
> binary, this is very important. How sensible is it to incorporate the
> contents of an environment variable directly into the first argument to
> fopen()? All relevant calls to fopen() are read-only (PG_BINARY_R).
>
> - Portability. The new code shouldn't be any less portable than the 7.1.3
> code, but I might have missed something.
>
> - Consistency. Is the configure script option (--with-odbc=DIR) properly
> named? I followed the convention set by --with-odbcinst, but the name I
> chose could conceivably be confused with --enable-odbc. It might be more
> appropriate (albeit less consistent) to call it --with-odbc-ini.
>
> - Should one obtain the current user's home directory from /etc/passwd by
> doing getpwuid(getuid()) or getpwuid(geteuid())? Currently I - like the
> 7.1.3 version of GetPrivateProfileString() - use the former, but it's
> something worth thinking about.
>
> - While I think I understand the somewhat convoluted code I replaced in
> GetPrivateProfileString(), I am occasionally wrong. ;)
>
> Feedback on these and any other issues would be very much appreciated.
>
> Regards,
> Ross Thomas
>
> ------------------------------------------------------------------------
> Name: ini-search-patch
> ini-search-patch Type: unspecified type (application/octet-stream)
> Encoding: quoted-printable
>
> ------------------------------------------------------------------------
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/users-lounge/docs/faq.html

In response to

Responses

Browse pgsql-patches by date

  From Date Subject
Next Message Tom Lane 2001-12-10 23:53:05 Re: Using Cursor in PostgreSQL 7.2
Previous Message Peter Eisentraut 2001-12-10 18:47:22 Re: NLS (Russian) - pg_dump update