FAQ Help On-line Trustware License News Contributed Code
Join IBO List List Archive What is IB Objects? Downloads
Events Tech Info Sheets IBO Community Links Home
 
IBO News

Firebird 1.5.3 Client Library Security Change
2 September 2005
Many IBO applications make use of the AlterUser methods of TIB_SessionBase or TIB_Connection to provide a quick way to maintain users and passwords in the security database. This method encapsulates the three API functions isc_add_user, isc_modify_user and isc_delete_user. For IB 5.6 and below, these functions provide the only way to maintain authentication records from a user application.

At some point, Borland introduced code into the API library, gds32.dll, to attempt to make an IB user on Windows who is logged in as Administrator acquire the same capability as a Unix (or Linux) user logged in as root, to access the security database without having to log in as SYSDBA. Hence, currently, when a client calls AlterUser() from an IBO application, one of the following will happen:

  1. if the Windows user is logged in as Administrator and the application does not supply the SYSDBA username and password, the client can perform the AlterUser functions

  2. if the Windows user is logged in as a non-Administrator but supplies the SYSDBA username and password that are correct for the server, the client can perform the AlterUser functions

  3. if the Windows user is logged in as Adminstrator and the application does supply the SYSDBA username and password, a variety of undesirable things will happen:
    • If the client is remote and there is a Firebird or InterBase server running locally and the SYSDBA password is the same on both servers, the local server will get the request and will try to update the local security database

    • If the client is remote and there is no Firebird or IB server running locally, the request will result in a number of exceptions related to Windows path resolution, that may be difficult to resolve without shutting down the server

The current situation is a source of concern to the security gurus in the Firebird development team, due to the way Windows systems are commonly set up. It is far from rare to find that many or all users on a Windows network are using the Administrator login. Implementations like IBO's AlterUser() therefore create a vulnerability for Firebird and InterBase servers, not only for Windows hosts but also for Linux hosts that are being accessed from a Windows application.

The Firebird core team has made the decision to close this hole in the Windows client library (fbclient.dll and fbembed.dll) for Firebird 2 and also to backport the change to the Firebird 1.5.3 release.

The changed client libraries are not in the Firebird 1.5.3 RC1 kits that are currently in the Firebird pre-release area for testing. They will appear in the v.1.5.3 RC2, due this month.

To test the change with any released version of Firebird (1.0.x or 1.5.x) currently in use, IBO users can download this version of fbclient.dll. Keep in mind that this version was compiled within the current Firebird 1.5 release environment and so carries the same build number as the Fb 1.5.2 release (4731). The compile date (18 Aug 2005) will be your only way to distinguish this file from the released version.

Firebird 1.5 and OldParameterOrdering [2]
November 2003
A solution has been introduced with the release of IBO v.4.3 to the parameter ordering workaround for applications accessing Firebird 1.5 servers. IBO now runs a special system query when it has connected to the server that can tell it that it is connected to a Firebird 1.5 server. It sets flags to determine how it will handle parameter ordering.

NOTE CAREFULLY that

  • OldParameterOrdering should be set to 0 (the default) for applications compiled with IBO 4.3 or higher

  • OldParameterOrdering should still be set to 1 for applications compiled with lower versions of IBO

Firebird 1.5 and OldParameterOrdering [1]
March 2003
IBO provides a transparent workaround for a long-standing InterBase bug that causes the ordering of return parameters to get scrambled, resulting in type mismatch exceptions or, worse, undetected wrong data when processing stored procedures.

The old bug is fixed in the Firebird 1.5 betas. Thus, the boot has changed to the other foot, meaning IBO would now "unscramble" parameters that are not scrambled. To preserve the old situation for IBO applications, the Firebird 1.5 server can be configured to deliver output parameters in the "wrong" order that IBO expects.

To set this up, do as follows:

  1. Open firebird.conf in a text editor and find the parameter named OldParameterOrdering
  2. Delete the '#' (comment) character
  3. Change the parameter setting to
       OldParameterOrdering = 1
    
  4. Save the changes
  5. Stop and restart the Firebird server

Be aware that the server will deliver the reordered parameters to all client applications, not just your IBO ones. This isn't a great solution so we'll be looking for a way to make it unnecessary.

Patch for compatibility with Firebird 1.0 INSERT syntax
19 March 2002
The latest IBO 4.2Gb confirms the Firebird 1.0 compatibility patch. I understand that Claudio Valderrama has already modified his change for the forthcoming Firebird 1.0.1 point release (thanks, Claudio!) In Firebird 2, which is already in alpha, this relaxation of SQL standards is to be disallowed.

BACKGROUND :: 14 March 2002
The release of the long-awaited Firebird 1 yesterday threw up a newly-introduced problem because of an unannounced new restriction on the SQL INSERT statement. Specifically, this unpublished change breaks IBO's parsing procedure so that, when inserting from a dataset, you will get this error:

ISC ERROR CODE:335544569

ISC ERROR MESSAGE:
Dynamic SQL Error
SQL error code = -104
Token unknown - line 1, char 34
.
Firebird 1.0 now makes it illegal to include table identifiers in the column-list for its SQL INSERT statement. This, for example, is now illegal:

INSERT INTO ATABLE ( ATABLE.FIELD1, ATABLE.FIELD2)
VALUES ( ... )

Under conditions where table aliases have been used to get the output for datasets, e.g. in self-joins and re-entrant joins, IBO depended on the capability of InterBase to allow table identifiers here.

I have posted a test patch (IBO 4.Gb_TEST) to work around the Firebird 1 problem but this will not currently solve the Firebird 1 incompatibility for sites where applications are deployed using previous versions of IBO.

The intention of the fix was to prevent illegal INSERT statements that crash the engine, like

INSERT INTO ATABLE ( ATABLE.*) VALUES ( ... )

The argument that "the restriction didn't break IBX or FIBPlus" is not a valid one. IBO utilizes this IB SQL language feature to provide live-dataset capability for joined datasets that involve table aliases. IBX and FIBPlus aren't affected because they don't provide this level of support for a very particular client/server requirement.

I ask that you test this patch hard, while we wait to hear from the Firebird team about modifying this fix. Let them fix what was intended to be fixed but not break a useful capability affecting many sites that have been waiting for the Firebird release.

IBO Trustware subscribers can download the patch IBO 4.2Gb_Test from the registered user area. Evaluation pack users can take the latest build from the Downloads page.


Some problems for Delphi 3 with IBO 4
IBO 4 introduced extensive use of object interfacing to extend and simplify the capability of the native controls to accept enhancements. Since Delphi supported object interfacing from Delphi 3 forward, it was not anticipated that this design decision would break anything.

However, it turned out that Delphi 3's implementation of OI is broken. If you have native IBO applications in Delphi 3 (or BCCPB 3) that use, or need to use features like edit masks and embedding controls in grids, stay with IBO 3 until you are ready to upgrade to a higher Delphi version.


IBO Passes Asta's Threadsafety Soak Test
(but the news isn't so good for IBX users)

from Derek Davidson, CTO
Asta Technology Group, Inc.

Following on from some requests from users and my own work, I have researched threading issues for our InterBase related servers.

Many of you are probably (rightly) enamored of the Open Source Edition of InterBase. The prospect of being able to deliver an application that uses an industrial grade C/S database, at no additional cost to you or the customer has to be attractive.

We at Asta provide support for a number of databases and we support connecting to InterBase through our BDE, InterBase Express, ODBC and IBObjects servers. Each of these servers has their own particular plus points, though it's fair to say that when it comes to deploying an InterBase solution, most people would use either InterBase Express or IBObjects as they give direct access to InterBase with the expected benefits of speed and accessibility.

Please note that I have NOT tested InterBase against either our ODBC or our BDE based servers and this is something that you may wish to do for yourselves. I can tell you that both of those servers do thread well under all normal circumstances.

Between InterBase Express and IBObjects, many select InterBase Express as it comes with Delphi itself (and is therefore free) and is also supported by Borland.

Following observations by some Asta users, we discovered that our InterBase Express (IBX) server was NOT thread safe. Our original response to this was, essentially, to blame InterBase. Our reply was based on threading issues that some InterBase users had reported in public newsgroups, concerning InterBase itself.

Notwithstanding, I researched as much as I could on the problem but was unable to produce an Asta IBX Server that threaded succesfully.

I then conducted tests with the Asta IB Objects (IBO) server. It passed our internal threading soak test without a single error. For us, this proved that the issue was not database related, but component related.

Therefore, with immediate effect, we regret to announce that we cannot support threaded Asta servers based on the Borland InterBase Express components. I will continue research in this area and will inform you as and when I am able to fix the extant issues.

For those users who do have customized InterBase Express based Asta servers, and want to use either of our multi-threading models, I strongly recommend changing over to IBObjects. I have made one such translation myself and this process took two days (including testing). If you need assistance in doing this, pleas feel free to contact me.


"The SQLDA bug"
This is the infamous bug in InterBase itself.

In version 3.6 Ba I changed the way IBO reacts to the ill effects of this bug. Here is what I said about it in the release notes:

I changed the code which automatically responds to the InterBase bug that mainly shows itself with executing stored procedures from remote clients, such that it won't execute it a second time in an auto-recovery situation, but instead will raise the exception.

IBO checks the StoredProcHasDML property value to determine what it has to do. Some people were complaining that their stored procedures were being executed twice and messing things up.

Now I have made it more obvious that there is a problem that should be worked around. The work-around is to put a SUSPEND in the stored procedure and then either use a TIB_Cursor or set the stored procedure component's StoredProcForSelect property to true. This way you avoid the API call that has the bug in it.

So, everyone, you need to work around this bug and not rely on IBO to smoothe it out. There is no safe way (generic) that I can do this for you.
 


We do it again!

IB Objects won the Delphi Informant Reader's Choice award for Best Database Connectivity product for the third year in a row. My thanks to our community for your votes and the magnificent help you all contribute to enhancing the power of IBO. We earned this together.
 
DelphiZine Reviews IB Objects
"For those who know InterBase®, IBObjects is a must-have tool set. If you don't know InterBase®, IBObjects is a good reason to learn it."
- So writes Robert Leahey, for Delphi Informant, in his review of IBObjects 3.4.
 
27 December 2000 :: My comments about the advantages of using IBO instead of IBX - article.
 
Firebird Open Source project
Supporting Open Source
Computer Programming Solutions supports the active development of the InterBase® source code by community developers on the Firebird Project at SourceForge. I plan to keep IB Objects releases in synch with both Borland InterBase® and Firebird distributions.

As announced in May 2000, I grant special rights of usage of the IBO technology, under terms compatible with the InterBase Public License, to projects that are truly open source. I will do all in my power to cooperate with those who want to get involved with IBO to accomplish their needs...MORE...
Jason Wharton
 

An OLE-DB Driver for IB 6.x
WORK-IN-PROGRESS
I have an early working version of an IB Objects-powered OLE-DB driver for IB 6.x ready for IBO developers to start on. Details here.