FreeTDS Development Group

[Brian Bruns <camber AT ais.org>]

On Wed, 30 May 2001, Lowden, James K wrote:
> Backwards compatibility: FWIW, I'm against it in this case, for the record.
> Too crufty.  I don't think it buys much, especially if "make; make install"
> migrates the interfaces file for you, and writes the environment settings to
> freetds.conf.  Not for nothing is perl "the duct tape of the Internet", eh?

The original target of FreeTDS was Sybase programmers and DBAs who were
quite familiar with the sybase way of doing things.  So, I like to think
of it as Sybase compatibility rather than backwards compatibility.  We may
trim extraneous options we've added in attempts to extend it
(~/.interfaces and the like), but I think looking for $SYBASE/interfaces
should remain as a fallback for the forseeable future.

> > Why not just use the --prefix from configure
> 
> Because it's nice to be able to relocate a configuration file without having
> to rebuild from source, and AFAIK there's no way to know what --prefix was
> used after "make clean".  That's not to say I'm sold on the idea, but that's
> the pro side.  
> 
> I'm suggesting, with reservations, a single environment variable pointing to
> the location of freetds.conf.  I agree, it shouldn't guide locating the
> libraries anymore.  And I agree life should be easy for the package makers,
> for they are the wind will carry FreeTDS to the four corners of the earth.  

Most linux based apps can't have their config files relocated
anyway.  Samba among them.  Linux is the tail wagging the dog i'm
afraid.  I'd prefer to be done with the env variables entirely. We'll
probably keep TDSDUMP for it's utilitarian value and SYBASE for the afore-
mentioned reasons, but down play their roles.

> On specifying the TDS protocol version
> 
> Brian, I understand your point about control and the value of being
> explicit.  How can we sidle our way toward more of a "what I've got" notion,
> instead of a "do this" one?  Most of the time, the FreeTDS program(mer)
> knows better than the user does what the optimal protocol version is, and
> when we're All Done, obviously no one is going to want to specify TDSVER
> anymore.  

I dunno...In principle, I agree. But the devil is in the details.  I'm
shelving this until after 0.52. Perhaps, at that point we may be able to
set 'tds version = negotiate' or something similiar for those brave
souls...too much work to think about right now. Negotation and reconnect
takes time, a valuable commoditity when a browser is waiting on the other
end.

> I'd like the user to see documentation like this:
> 
> <documentation doodle>
> Specify your database server's vendor {SYBASE|MICROSOFT} and version as
> follows:
>       db vendor = SYBASE      ; or MICROSOFT
>       db version = 10 ; of 4.x, 10.x, 11.x, 12.x, 6.0, 6.5, 7.0, 2000
> 
> If you indicate a log file in freetds.conf, the TDS protocol chosen will be
> logged.  Normally, FreeTDS uses the highest protocol appropriate for your
> server, but for debugging purposes you can downgrade the protocol with the
> line:
>       
>       tds version = 4.2       ; of 4.2, 5.0, 7.0
> 
> Don't put that in your [globals] section unless you really mean it!
> </doodle>

Ok, fine...And then microsoft releases new improved SQL Server 2001 and a
Half! And the code doesn't know what to do with it until poor joe shmoe,
whose evil DBA performed the trecherous upgrade, has to get an emergency
CVS bug fix version to be back in business!

Tracking vendor changes is a nightmare...tracking features is much
easier... and besides you didn't mention Sybase Replication Server, Sybase
OpenServer applications, Sybase Adaptive Server Anywhere, and all those
other products that don't fit neatly into this scheme.  Sybase ASA btw
does not fall back to TDS 4.2 interestingly enough.

> On domain login negotiation
> 
> Good points all around about clarity in reporting failed logins.  Here's a
> bit of self-important MS documentation:
> 
> "By setting the secure connection flag in a LOGINREC structure with
> DBSETLSECURE, the application requests a secure, or trusted, connection to
> Microsoft® SQL Server(tm). This means that SQL Server will use Windows NT
> Authentication security to establish connections made (using dbopen) with
> this LOGINREC, regardless of the current login security mode at the server.
> Any login ID or password supplied by DBSETLUSER or DBSETLPWD is ignored."  

DBSETLSECURE is an MSism...not inherited from Sybase.  Anyway, it is a
programatic setting and has little to do with the config file per se.

> Steve, does that answer your question about NT clients?  From db-lib's point
> of view, your DSN is an application.  If you have other NT questions, ask
> away; it's what I do.  
> 
> Each db-lib connection (at bottom, every TDS connection) decides
> per-connection what authentication system to use.  Microsoft applications,
> including ISQL, rely on domain logins unless the user takes some action
> (normally, providing a username) to override that.  In principle, conforming
> to MS's own behavior should make FreeTDS invisible.  You heard it here
> first: Good design is invisible.  

I guess I am a little confused about what goes on under the covers with
trusted connections.  Is it just that TDS is ridden over an
already existing SMB/RPC connection and therefore is automatically
trusted? Couldn't be because the SQL Server may not be the same as the
PDC, correct?  Which means the auth must occur at some point anyway.

I know Windows caches passwords used to authenticate and will attempt to
automagically log you on to a new resource before prompting (happens for
us with novell and samba on unix). 

If so, what does that mean for FreeTDS? I have some SMB traces from Steve
that I need to look into.  I'm so confused!

> Well said, again.  Respectfully, I disagree because:
> 
> Preventing some negotiation with a library setting will break the
> DBSETLSECURE behavior as documented.  

Programatic settings *always* override config settings in freetds,
always. If an application specifically calls DBSETLSECURE(), which doesn't
yet exists, by the way, then that behaviour is honored.  Now, that is
specific to dblib only and you'd be hard pressed to find an application
that uses it (unless you where porting existing dblib windows apps to
linux).  I suppose there is an ODBC call that does this too?

> Whatever the settings are in freetds.conf, they have to conform to what the
> server's settings are.  They can't be anything else, or they're broken.
> There's no  (OK, almost no) point in redescribing the server's settings in
> the library's configuration file.  The opportunity to get out of synch
> outweighs IMHO the value of faster negotiation and less spammy logs.  

Ahh, but several values for each setting may be valid.  ie 'tds version'
could be 4.2 or 7.0, 'server logins' or 'domain logins' could both be used
if the server was configured as 'both'.  On the other hand, 7.0 GA and SP1
need 'broken dates' on big endian machines, but SP 2 (or is it 3) can not
have them.  So you have to be very specific.

Again, tracking versions is much more difficult than tracking
features.  People will have to upgrade FreeTDS constantly to keep up with
the vendors whims, and I guarentee that freetds' users get new software
before I do.  The biggest reason why we have no TDS 8 support is that I
don't have SQL 2000 (or network traces from the same...hint hint people), 
which has been out for quite some time.

> All to say, it's the server's job in the end, anyway.  Consider how Samba or
> ftpd works.  If your log files fill up with refused connection messages, you
> yell at the fool, er, talk to the user/developer about login policy.  
> 
> +++
> 
> "unless Brian's getting very ambitious here :), the client app will still
> always have to supply the username & password, even in domain auth mode"
> 
> If this is true, I know I'm missing something.  I can tell, because it feels
> different from missing something and not knowing it.  
> 
> What does the client app know that FreeTDS can't know (about
> authentication)?  Why wouldn't FreeTDS get the credentials and, yes, cache
> them, and honor DBSETLSECURE, etc.?  Why is that "ambitious"?  What easier
> way is there, to manage domain authentication?  
> 
> As I said, it's fun learning (even if it's not short).  

What the client app knows is the existing SMB connection (which generally
would not exist under *nix), or the cached password from the same.

Perhaps, PAM SMB is our saviour here? 

The whole thing reeks of insecurity.

B.