Skip to Content.
Sympa Menu

freetds - [freetds] auto login protocol retry (was Re: ignore --tdsver)

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Mike Slifcak <slif AT bellsouth.net>
  • To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: [freetds] auto login protocol retry (was Re: ignore --tdsver)
  • Date: Wed, 14 Sep 2011 12:49:31 -0400

Bob,
You bring up an interesting point.

There may be some sites that model what a 'good' application does. Hunting with a number of rejected requests from the same source server may look like an unauthorized probe.

Explaining why a previously vetted application has changed behavior that now violates site policy would tend to inhibit acceptance of the new release.


James,
Would you consider the auto login feature not be compiled in unless the
package builder
specifies a configure option to use it?

Benefits for making auto login feature configured at build time only
include:
1. Increased confidence in the user community that using the new release does not produce unexpected changes in behavior. This will tend to speed migration to the new release.

2. There is a low probability that the un-compiled feature can be blamed
for some error.

3. Any proven existing troubleshooting procedure might be vetted with
minimal change.

4. Applications linked to the new release are not likely to leverage the
un-compiled
feature for malicious intent nor suspicious mistake.

5. Re-qualifying existing applications built to the new release is easier when existing test plans are not required to cover a new feature.

Thank you for considering this.
-Mike Slifcak



Bob Hetzel wrote:
James,

Regarding re-trying the login with each protocol until it finds a good one... is there any chance that'll cause an account lock-out if a place has really tight security settings?

I guess the real question I'm asking is... how far will it get when it fails due to the wrong tds version for that server? If it fails before sending the username/password then there would probably not be a problem. After that point, it might be. This would probably only be an issue if using a windows logon (rather than a sql only account), but I did just stumble onto this:

http://technet.microsoft.com/en-us/library/bb326598.aspx

referenced from

http://www.derkeiler.com/Newsgroups/microsoft.public.sqlserver.security/2008-01/msg00016.html

Bob

On 9/8/2011 11:08 PM, James K. Lowden wrote:
On Thu, 08 Sep 2011 12:22:14 -0500
"Craig A. Berry"<craigberry AT mac.com> wrote:

5.0 may not be a sensible default in this day and age. But I'm not
sure there is a different one that makes sense either.
I'd like to riff on that a bit. The right default might be "auto",
which is currently supported in, er, CVS HEAD.

The recent discussion of dbsetversion() is illustrative. The
documentation says if you don't call it, you get TDS 4.2. That makes
sense: recompile old code, link to new library, get same behavior. To
get new behavior, call the (previously nonexistent) function.

But it also doesn't make sense. Write brand new code, and to get
modern behavior you have call the (otherwise meaningless) function.
ODBC has been stuck with this for a decade, cf. SQL_ATTR_ODBC_VERSION.
You actually call the API to change the API.

Larry Wall mentioned a similar artifact once in writing about Perl 6.
He remembered IIRC a setting in VMS mumble something like SET EXTENDED
ON to make it DTRT. He observed that thereafter *every* script needed
that boilerplate in its preamble. One gets the sense Larry is not a fan
of boilerplate or, for that matter, preambles.

That's the world of binary interfaces and closed source. Free
software lets you set the "default defaults" with ./configure. Because
you control the source, you can set the default at compile time, which
is why the inoperability of dbset[l]version went unremarked-on for
years.

If we were to remove --with-tdsver (which we won't) we'd remove
only the ability to set the compiled-in default. If you don't use that
configure option, you get 5.0. It has to be *something*, even if it's
an invalid value that forces you to use one of the runtime or
programatic methods to set it to something valid.

Which brings us back to: what should it be?

Which makes me ask: what's a configure file for, anyway?

freetds.conf associates a hostname, port, and TDS version with a local
name. Hostname is converted to an IP address by DNS or similar. Port
is discoverable on Microsoft servers using 1434. And TDS version can
be found by starting high and working down. Old servers reject
logins using newer versions of the protocol; from their perspective the
new version is a protocol violation. By trying successively lower
version, a client can discover the highest one supported by a server.

What that means to me is that FreeTDS in its next release should
normally be run without a configuration file or environment variables.
The default-default TDS version should be 0, which tells the login
function to keep trying TDS flavors as long as something accepts the
tcp/ip connection.

That said, there is miniscule overhead in retrying logins, and it is
unnecessary if you know which TDS version the server wants, and for
some applications a few hundred milliseconds' delay to log in
matters. The spirit of the project demands that users be able to nail
things down, even to the point of setting the compiled-in default
behavior.

End of Riff. Thanks for listening.

--jkl
_______________________________________________
FreeTDS mailing list
FreeTDS AT lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/freetds
_______________________________________________
FreeTDS mailing list
FreeTDS AT lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/freetds





Archive powered by MHonArc 2.6.24.

Top of Page