FreeTDS Development Group

["James K. Lowden" <jklowden AT speakeasy.org>]

Brian, thank you for explaining a few things to me.  I'll (mostly) just try 
to answer
a few questions.

Brian Bruns wrote:

> I think looking for $SYBASE/interfaces
> should remain as a fallback for the forseeable future.

right.

> Most linux based apps can't have their config files relocated

oh.

> > On specifying the TDS protocol version
> In principle, I agree. But the devil is in the details.  I'm
> shelving this until after 0.52.

I understand.  No need for this to be in .52, surely.

> 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.

More to learn on my part, I see.  Let's see how ambitious I get.  If I handed 
you a
module that (a) read an .ini file like the one I described and (b) made 
guesses about
things it didn't know about (like future versions), and (c) looked up the 
TDSVER in
its private translation table, basically an STL std::map, would that interest 
you?
Remember, overrides are still available with an explicit statement in the
freetds.conf.  And I'm localizing the server-to-protocol lookup to such a 
degree that
it's nearly as easy to encode as to document.

> > On domain login negotiation
>
> 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!

*You're* confused!   If that doesn't sound like trouble.... :-)  I don't see 
why
youofallpeople should be confused about an opaque system documented by the 
very
doubletalk people Orwell warned us about who occassionally and then only by 
luck
adopt precisely antonymical terminology when it suits them.  What's so bad 
about
that, after you get used to it?

IIRC, PDCs have themselves some sort of trusted domain, such that if client C 
is
authenticated by PCD P1 and wants to connect to (log into) server S, then S 
and C do
not both have to use P1 for authentication.  S may be in another domain 
controlled by
PDC P2, and P1 and P2 have some mumble mumble arrangement to cross manage
authentication or whatever you'd call it.

Windows doesn't cache the password, not really.  Rather, it caches a security 
token,
acquired from some authentication source (local or PDC), which it passes as
necessary.  This obviates the need for each NT box to do authentication or 
even have
accounts; your account at the PDC is good enough for all members.  But you 
knew that
already.

I was all out of breath from leaping to the conclusion that the 150-odd lines 
of code
you're using did more-or-less the same thing viz., requested a security token 
from
the PDC, which you'd cache and then have ready when the time comes.  I see 
now that
even if that were so (which now looks less likely), there would still be the
significant challenge of figuring out where to squirt that token into the TDS
stream.  Ugh.

The answer has to be somewhere in Samba under smbclient, doesn't it?  Do you 
need a
research assistant on this?

> 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?

I understand your point.  Quite true, I'd be "hard pressed to find" something 
that
worked that way in the *nix world, if for no other reason than that there's no
implementation of a db-lib that supports it!  OTOH, it's the usual way in the 
MS
world.

The real point is that it's a good way.  It's clear, flexible, and adheres 
pretty
closely (allowing for the effects of Microsoft) to the principle of least 
surprise.
I'm being noisy here because I don't want the marvelous addition of domain 
logins to
be misconstrued as a server or client attribute.  Properly, it's a session 
attribute.

Dblib uses DBSETLSECURE.
Odbc uses Trusted_Connection = Yes.  See
http://larr.unm.edu/~owen/SQLBOL70/html/odbc_d_2.htm and
http://larr.unm.edu/~owen/SQLBOL70/html/odbc_c_4.htm.  Note it can be set for 
the
datasource or for the connection.
Ctlib uses ... oh, too bad.  Thank you for playing.  Ctlib uses Sybase.

One could take the position that no username implies a domain login.  That 
would have
the advantage of not requiring any API change to the client libraries.  It 
would also
not mimic Microsoft's "standard".  How faithfully you want to re-implement 
their
libraries, well, it's a choice, isn't it?

> > 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.

Downgrading the TDS version has to be possible, as you point out, so it has 
to remain
a (eventually possibly optional) feature of freetds.conf.

Your point about the dates, granted.  Date brokeness is not exactly a version 
feature
or a server setting; it necessitates fussiness in the config file as a cost 
of vendor
independence.

What good are authentication settings, though?  The server either accepts or 
rejects
domain logins; the library cannot affect that.  The server either accepts or 
rejects
server logins; the library cannot affect that.  The programmer must -- in my 
view --
set the kind of authentication he wants per connection, which the library has 
merely
to pass on to the server for it to either accept or reject.  Why force the 
client
administrator to maintain settings he only dimly understands and in any case 
cannot
control, when it's the server's call and the sa's choice & whim?


> 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.

[I guess I'm not completely done expressing an opinon.  At least this *is* a 
config
file issue.]

I'm completely sympathetic.  I'm just a little more optimistic than you are 
about
being able to completely specify the suite of server systems that now exist, 
and more
prepared than you are to guess about things I've never heard of.  Taking your
example, when MS SQL Server 2001.25b XP SP7a comes out, my heuristic would be,
simply, "Gee, that's really big compared to SQL Server 2000.  Guess I'll go 
with TDS
7.0".  Until it's documented in some way, the user's guess isn't going to be 
any
better.  If it's a really lousy guess, it's TDS override time, at least until 
the
next release.

Transparency is very important in this regard.  I think that a low level of 
verbosity
setting should echo the configuration settings and inferences (especially 
guesses) to
the log file per connection, for diagnostic purposes.  Remember the last time 
you
misspelled a keyword in a config file and the app reverted to its default 
instead,
never missing a beat, never complaining?  What?  Never happened to you?  Wow. 
 All
I can say is, Wow.

> 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?

I'm sorry.  I don't get this.  It sounds like the client would have to use 
some other
library to get itself authenticated and then ask FreeTDS to piggyback on that 
link?
My hope is that FreeTDS will do all the dirty work and expose one or two tiny 
APIs to
effect domain logins.

> The whole thing reeks of insecurity.

You said it.  In any other context, "secure connection" has at least 
something to do
with encryption vs. cleartext.  Not here.  Here it means "proprietary murky
security-through-obscurity authentication protocol".  You don't know how much 
I've
had to unlearn.

--jkl