FreeTDS Development Group

["Peter C. Norton" <spacey-freetds.org AT ssr.com>]

Greetings lists,

I'm a new freetds user, tasked with upgrading our database clients.
At my work I've been tasked with "making unix clients work with AD and
MSSQL".

Basic kerberos support works by default with the version of FreeTDS
that we're using (snapshot 0.82.1.dev.20091223), but we noticed that
support for delegation of principles isn't supported, and we do a lot
of bcp/BULK INSERTs from applications running as various users.  We
also want to benefit from the constant flow of bug fixes and
improvements that have come in over time, so I've been working with a
0.83 snapshot from the beginning of september. 

To support delegation, I've found that aside from the AD
infrastructure knobs, from the freetds side we only need need to add
the proper flag to the call to gss_init_sec_context() call.  Since we
don't want to request delegation to any arbitrary connection, we want
this to be configurable on a per-server basis, and to default to off,
which seem like sane defaults.

I've hacked in some simple support for this with very minor edits to
gssapi.c, tds.h, and config.c.  The support adds a new config option
to freetds.conf that adds a boolean config option of "enable gssapi
delegation = <true|false>" by adding a couple of defines in tds.h and an
additional value to the TDSCONNECTION struct.

So my first question is: Would this minor addition be accepted into
the mainline freetds by the maintainers?

In addition, we prefer to enable the mutual and reply flags.  For us,
we always want these to be enabled, but I'm open to the idea of having
them be additional per-server options if that's considered the "right
thing" by the maintainers.

Second, we've found that under some circumstances, there are now 2
tests that fail under Solaris 10 x86.  

Test #1 is in src/dblib/unittests/done_handling.c:err_handler.  The fix is:

diff -r 0de86646fcd3 src/dblib/unittests/done_handling.c
--- a/src/dblib/unittests/done_handling.c       Tue Sep 14 15:57:39 2010 -0400
+++ b/src/dblib/unittests/done_handling.c       Wed Sep 15 11:00:02 2010 -0400
@@ -221,8 +221,14 @@
        fflush(stdout);
        fprintf(stderr, "DB-Library error (severity %d):\n\t%s\n", severity, 
dberrstr);
 
-       if (oserr != DBNOERR)
-               fprintf(stderr, "Operating-system error:\n\t%s\n", oserrstr);
+       if (oserr != DBNOERR) {
+               if (oserrstr != NULL) {
+                       fprintf(stderr, "Operating-system error:\n\t%s\n", 
oserrstr);
+               } else {
+                       fprintf(stderr, "Operating-system error, NULL error 
string (probable bogon in the test)\n", oserrstr);
+               }
+               
+       }
        fflush(stderr);
 
        return INT_CANCEL;

it seems that on recent updates to Solaris 10, if oserrstr is NULL,
the test will segfault.  In prior updates to the OS, this test passed.
The man page for fprintf only specifies that passing in a non-null
terminated pointer to the *printf calls will result in "unspecified
behavior", while it seems like on linux, glibc will protect the caller
by printing something like (null).

Test #2 is in src/ctlib/unittests/cancel.c.  I don't have a fix at the
moment, and I don't know if the failure is of an OS-specific nature,
but this one actually bothers me more because it seems like the
expected behavior of setting a SIGALARM handler isn't working properly:

~/work/freetds-0.83.dev.20100902/src/ctlib/unittests $ ./cancel
cancel.c: Check asynchronous called ct_cancel()
connecting as sa to SYBQA1.tempdb
SYBQA1 Message 5704 severity 10 state 1 line 0:
        "Changed client character set setting to 'iso_1'.
"
Changed database context to 'master'.

Changed database context to 'tempdb'.

More results?...
do_fetch retrieved 10000 rows
do_fetch() returned: 0
More results?...
All rows read, this may not occur.

I expect this to match the output at
http://freetds.sourceforge.net/up/out82/test3/ctlib_cancel.1.html,
which it doesnt :(

I'm able to tests out any suggestions for the next few days.

Thanks,

-Peter