headers
Aistis Jokubauskas | 24 Apr 2013 11:29
Favicon
Gravatar

ODBC driver information

Hi,

is it possible to get odbc driver information. I would like to get 
driver name and version using odbc api.

--

-- 
Have a nice day,
Aistis Jokubauskas

_______________________________________________
unixODBC-dev mailing list
unixODBC-dev <at> mailman.unixodbc.org
http://mailman.unixodbc.org/mailman/listinfo/unixodbc-dev
Permalink | Reply | 2 comments |
headers
k_runarsson | 12 Apr 2013 12:23
Picon

Compiling unixODBC with MySQL driver on AIX

Hello,
I'm trying to get unixODBC working on AIX 7.1, so far I have done the following:

1) I have downloaded unixODBC 2.3.0 and compiled it with the following options:

export CC=xlc_r
export CXX=xlC_r
export CFLAGS="-q32 -qlanglvl=extended -ma -O2 -g -qstrict -qoptimize=2 -qmaxmem=8192"
export CXXFLAGS="-q32 -ma -O2 -g -qstrict -qoptimize=2 -qmaxmem=8192"
export LDFLAGS="-Wl,-brtl"
export OBJECT_MODE=32

./configure --enable-gui=no --enable-drivers=no > c.log

N.B: The install script does not seem work correctly on AIX 7.1.

2) I then downloaded MySQL 5.6.10:

wget
http://dev.mysql.com/get/Downloads/MySQL-5.6/mysql-5.6.10.tar.gz/from/http://cdn.mysql.com/
-O mysql-5.6.10.tar.gz

and added the following to CMakeLists.txt:

SET(CMAKE_C_FLAGS "-q32 -qlanglvl=extended -ma -O2 -g -qstrict -qoptimize=2 -qmaxmem=8192 -lC
-liconv" CACHE STRING "Forced C compiler flags." FORCE)
SET(CMAKE_CXX_FLAGS "-q32 -ma -O2 -g -qstrict -qoptimize=2 -qmaxmem=8192" CACHE STRING "Forced C++
compiler flags." FORCE)
SET(CMAKE_C_COMPILER "/usr/vac/bin/xlc_r")
SET(CMAKE_CXX_COMPILER "/usr/vacpp/bin/xlC_r")
(Continue reading)

Permalink | Reply | 1 comment |
headers
xiaonan | 12 Apr 2013 03:40
Favicon

lt_dlerror may cause potential issue in multi-thread environment

 Hi, Nick:

    Because lt_dlerror() function is not thread-safe, in the following code:
    
    if ( !(connection -> dl_handle = odbc_dlopen( driver_lib )))
    {
        char txt[ 2048 ];

        sprintf( txt, "Can't open lib '%s' : %s",
                driver_lib, lt_dlerror());

        ......
        
        return 0;
    }
 &nbsp ;  
    In multi-thread environment, the lt_dlerror() may return other thread's error, or even NULL.
    
    In your latest modif! ication:
    
    if ( !(connection -> dl_handle = odbc_dlopen( driver_lib )))
    {
        char txt[ 2048 ];
        const char *err;

        err = lt_dlerror();

        sprintf( txt, "Can't open lib '%s' : %s",
                driver_lib, err ? err : "NULL ERROR RETURN" );

        ......
        return 0;
    }
    
    This issue still exits.
   &nbs p;
    Personally, I think the function of odbc_dlopen() can be modified as this:
    
    static void *odbc_dlopen( char *libname, cha! r *err );
    {
        ......
        hand = lt_dlopen( libname );
        if (hand)
        {
        }
        else
        {
            sprintf(err, "%s", lt_dlerror());
        }
    }
    
    So if there is a error, the error can be returned correctly:
    
    char txt[ 2048 ];
    char err[2048]
    if ( !(connection -> dl_handle = odbc_dlopen( driver_lib, err)))
    {
        
    &nbs! p;   sprintf( txt, "Can't open lib '%s' : %s",
 &nbs! p;              driver_lib, err);

        ......
        
        return 0;
    }
    
    Could you help to check it? Thanks very much!
    
Best Regards
Nan Xiao


_______________________________________________
unixODBC-dev mailing list
unixODBC-dev <at> mailman.unixodbc.org
http://mailman.unixodbc.org/mailman/listinfo/unixodbc-dev
Permalink | Reply | 3 comments |
headers
Prasanna Srinivasan | 12 Apr 2013 03:37
Picon

RHEL 5 Linux UnixODBC/Freetds

Am trying to move my compiled C code that connects to mssql database
servers from using the datadirect odbc drivers to using the unixodbc
driver manager (version 2.3.1)/ freetds drivers (version 0.91) which
are already compiled for 64 bit and available to me.

Am able to successfully compile it on 64 bit RHEL5 Linux by linking in
libodbc which has already been compiled. But I get the error
net.c:350: tds_select: Assertion 'timeout_seconds >= 0' failed
multiple times when I run the code and the database connection fails.

The environment variables I set are ODBCINI, ODBCHOME and
LDD_LIBRARY_PATH (which is set to the libraries in the unixodbc path).
The driver in the odbcinst file is set to the path where libtdsodbc.so
is located.
 The permissions on the odbc.ini, odbcinst.ini files appear to be fine.

I also tried linking in libodbinst and libtdsodbc (by including and
not including libodbc)  when compiling and set the FREETDSCONF
environment variable as well to the freetds.conf location. But I keep
getting the same error, "net.c:350: tds_select: Assertion
'timeout_seconds >= 0' '. My code connects to the database
occasionally, but for most of the part it errors.

The timeout from the freetds.conf file appears to be correct:
-----------------------------------------------------
   # Command and connection timeouts
;       timeout = 10
;       connect timeout = 10
--------------------------------------------------

When I do an ldd on my executable, the dependencies are:

libodbcinst.so.2 =>
libtdsodbc.so.0 =>
 libnsl.so.1 =>
 libc.so.6 =>
 libdl.so.2 =>
 libpthread.so.0 =>
 librt.so.1 =>
 /lib64/ld-linux-x86-64.so.2

Am I missing something here.

Thanks for your help.
_______________________________________________
unixODBC-dev mailing list
unixODBC-dev <at> mailman.unixodbc.org
http://mailman.unixodbc.org/mailman/listinfo/unixodbc-dev
Permalink | Reply | 2 comments |
headers
xiaonan | 11 Apr 2013 08:24
Favicon

A multi-thread contention issue when using lt_dlinit function

 Hi, Nick:

    Sorry for interrupting you again!
    
    Because libltdl functions are not thread-safe (http://www.gnu.org/software/libtool/manual/html_node/Thread-Safety-in-libltdl.html), we should add lock before using them.
    
    In __connect_part_one function:
    {
        ......
        /*
         * initialize libtool
         */
    
        lt_dlinit();
        .... ..
        
        if ( !(connection -> dl_handle = odbc_dlopen( driver_lib )))
      &nbsp! ; {
           ......
        }
     }
    
     int lt_dlinit (void)
     {
         ......
         if (++initialized == 1)
         {
            ......
         }
    
     }
    
     In multi-thread environment, there will be a scenario: Thread 1 calls lt_dlinit(), and the initialized's value is 1. Then Thread 2 calls lt_dlinit(), and the initialized's value is changed to 2. Thread 2 thinks the initializtion is OK, so it will continue executing and calls odbc_dlopen(). But in fact, the initialization isn't done! So odbc_dlopen() will return NU! LL.
    
     So I think we should add lock before using lt_dlinit(), such as:
    
     mutex_lib_entry();
     lt_dlinit();
     mutex_lib_exit();
         
     Is it OK? Thanks very much!
 
 Best Regards
 Nan Xiao


_______________________________________________
unixODBC-dev mailing list
unixODBC-dev <at> mailman.unixodbc.org
http://mailman.unixodbc.org/mailman/listinfo/unixodbc-dev
Permalink | Reply | 2 comments |
headers
Динар Рахимбаев | 10 Apr 2013 17:45
Picon
Favicon

ODBC-api hooking problem

Good afternoon!

I have a problem of hooking ODBC-api calls to perform some authority 
check of SQL-requests. I decided that it is possible if I developed my 
own driver, which would pass calls from driver manager  to the next 
DBMS-specific driver, or again to the driver manager(driver manager then 
would call DBMS specific driver) after authority check.
I decided to implement my custom driver by the second way (i.e. driver 
passes calls to the driver manager), because the driver manager performs 
many routine work of managing environment and connections. So my custom 
driver loads the driver manager (libodbc.so) using dlmopen(), extracts 
the entry points using dlsym(), then just passes calls to the 
corresponding functions of newly loaded driver manager.

I'm getting SIGSEGV when my driver passes the call to driver manager's 
SQLConnect() function.

So my question is: is it possible at all to use the driver manager in a 
such scheme?

/****************************************************

Applicaion -> Driver manager 1 -> My custom driver(hook) -> Driver 
manager 2 -> DBMS specific driver.

****************************************************/

If not, maybe you have some ideas on how to do it using ODBC? Saying 
again: I need to perform authority check of SQL-requests before requests 
are passed to DBMS. Moreover, I must be able to reject unauthorized 
requests.

Thank you for attention!
_______________________________________________
unixODBC-dev mailing list
unixODBC-dev <at> mailman.unixodbc.org
http://mailman.unixodbc.org/mailman/listinfo/unixodbc-dev
Permalink | Reply | 4 comments |
headers
xiaonan | 10 Apr 2013 11:17
Favicon

A core dump issue in __connect_part_one function

 Hi, Nick:

    Sorry for interrupting you!
    
    When I using unixODBC, there will be core dump sometimes. The cause is in __connect_part_one and __connect_part_two functions:
    
    if ( !(connection -> dl_handle = odbc_dlopen( driver_lib )))
        {
            char txt[ 2048 ];

            sprintf( txt, "Can't open lib '%s' : %s",
                    driver_ lib, lt_dlerror());
            ......
         }
     &nbsp! ;   
         The lt_dlerror() return value is NULL.
         
         Because lt_dlerror() can return NULL, I think we should justify the return value of lt_dlerror before using sprintf.
         
         BTW, I think LT__GETERROR and LT__SETERRORSTR are not thread-safe, so the return value of lt_dlerror can be NULL.
 
Best Regards
Nan Xiao
    


_______________________________________________
unixODBC-dev mailing list
unixODBC-dev <at> mailman.unixodbc.org
http://mailman.unixodbc.org/mailman/listinfo/unixodbc-dev
Permalink | Reply | 1 comment |
headers
Heikki Linnakangas | 28 Feb 2013 09:04
Favicon

Handling out-of-memory

Hi,

While working on the PostgreSQL driver, I bumped into two little bugs in 
handling out-of-memory situation. Patch attached. It's probably 
self-evident from the patch what the bugs are, but I'll explain anyway:

1. In __post_internal_error_ex, check for NULL return from malloc, and 
avoid some unnecessary allocations so that we don't need to handle the 
case that they fail. (In my test case, the reason that 
__post_internal_error_ex got called in the first place was that dlopen() 
failed with Out-of-Memory while loading the driver, so it's not 
surprising that those allocations failed too)

2. In __alloc_desc, there is a check for calloc returning NULL, but some 
of the initialization code was misplaced, and was being called on the 
NULL pointer anyway.

There are a lot more places where we don't check for malloc returning 
NULL, but fixing those two made my test case work. In the test case, I 
opened a large number of connections, and to induce the OOM condition, I 
ran it with a small "ulimit -v".

- Heikki
Attachment (fix-oom-crash.patch): text/x-diff, 9 KiB
_______________________________________________
unixODBC-dev mailing list
unixODBC-dev <at> mailman.unixodbc.org
http://mailman.unixodbc.org/mailman/listinfo/unixodbc-dev
Permalink | Reply | 1 comment |
headers
Nick Gorham | 31 Jan 2013 00:08
Favicon

Re: iconv leak

On 30/01/13 16:10, Todor Buyukliev wrote:
> hi, nick!
>
> in one of our applications we found leaked structures allocated by iconv_open() from unixODBC. i read the
source and the only way i see this could happen is by failure in __connect_part_one().
__connect_part_one() is called by all SQLConnect() variants and no cleanup is done on failure, despite
that memory might have been allocated. what's worse is that in this case the connection is left in STATE_C2
and even if SQLDisconnect() is called the memory will not be freed.
>
> one approach for fixing this is in the attached patch. does it look ok to you? i haven't reproduced the issue
and haven't confirmed that the patch doesn't break anything.
>
> pooling is not enabled in our setup, so i haven't inspected the pooling code.
>
> regards,
> todor
I have added this fix to the source and built a 2.3.2-pre tarball with 
it in on the ftp site.

--

-- 
Nick
_______________________________________________
unixODBC-dev mailing list
unixODBC-dev <at> mailman.unixodbc.org
http://mailman.unixodbc.org/mailman/listinfo/unixodbc-dev
Permalink | Reply | 0 comments |
headers
xiaonan | 20 Nov 2012 10:28
Favicon

A issue about return_to_pool function

 Hi, Nick:
    Sorry for interrupting you.

    In return_to_pool() function, I think the unicode_driver should also be set:
   ptr -> connection.unicode_driver = connection ->unicode_driver;

   If this value not set, the search_for_pool() return the connection's unicode_drive's value is always 0. This will lead error when using unicode driver.

    Please help to check it, thanks very much!!

Best Regards
Nan Xiao






_______________________________________________
unixODBC-dev mailing list
unixODBC-dev <at> mailman.unixodbc.org
http://mailman.unixodbc.org/mailman/listinfo/unixodbc-dev
Permalink | Reply | 1 comment |
headers
Auburn Study | 8 Nov 2012 15:48
Picon

Buffer Overflow Study at Auburn University - unixODBC developers I would really appreciate your help!

Hi All,

I am a graduate student at Auburn University, working with Dr. Munawar
Hafiz. We are working on an empirical study project to understand the
software engineering practices used in companies that produce secure
software. In particular, we are concentrating on how developers write
code to prevent buffer overflow and integer overflow vulnerabilities.
We are interested in the software development process: how you develop
software, how you test and analyze programs to detect vulnerabilities,
and what processes you follow to remove bugs. We are looking into
automated tools that software developers use, and are expecting that
there is a common insight in the security engineering process that can
be reusable.

We request your assistance by participating in this research study.
We would greatly appreciate it if you would share your experience with
us by answering the questions at the end of this email. We may send
some follow up questions based on your response in future. Your
response(s) will be kept confidential, and will only be aggregated
with those of other responders. Please let us know if you have any
questions or concerns regarding the study. Thanks in advance for your
support.

Yasmeen Rawajfih
Software Analysis, Transformations and Security Group
Auburn University

Working under the supervision of:
Dr. Munawar Hafiz
Assistant Professor
Dept. of Computer Science and Software Engineering
Auburn University
Auburn, AL
http://munawarhafiz.com/

Questions: (There are ten questions.)

1.       How long have you been a software developer?

2.       How long have you been affiliated with unixODBC? Were you
part of the original development team for this software?

3.       What is the size of the current code base?

4.       Did you follow a coding standard when developing this
software? Is it a standard determined by your group?t

5.       What did you use to manage bug reports in your software? Does
it satisfy your requirements? Are there other software options that
you would consider switching to?

6.       Did you use any compiler options to detect integer overflow
vulnerabilities? Do you think that they are useful?

7.       Did you use any automated (static or dynamic analysis) tools
to detect buffer overflows, integer overflows, or any other bugs?
Which tools did you use? Why these tools?

8.       Did you use fuzzing? Which tools did you use and why? If you
wrote your own fuzzer, why did you write it yourself? Was it written
from scratch or by extending some other fuzzing tools?

9.       Did you have specific phases during development where you
concentrated on fixing security issues? Did you have a test suite,
unit tests, or regression tests?

10.   Buffer overflows often result from the use of unsafe functions,
such as strcpy. Does your software use those? If you use a different
string library, why is it used? Is it an in-house library or an
off-the-shelf library? Did you migrate your code to use the string
library?
_______________________________________________
unixODBC-dev mailing list
unixODBC-dev <at> mailman.unixodbc.org
http://mailman.unixodbc.org/mailman/listinfo/unixodbc-dev
Permalink | Reply | 0 comments |

Gmane