At 09:12 AM 15-09-01 +1000, you wrote:

> > Confusion here - first, there is no "Phoenix
> > version"; and, secondly, Firebird has no
> > licensing code whatsoever.
>
>My mistake. I had thought that IB Phoenix was going to produce a
>version capable of being licenced - to give developers the ability to
>control access.

No. IBP has coders working on the Firebird project but their stuff isn't separate.

As to the licensing code, yes, it's still in there (commented out) so it would be possible to build a version that intercepts client connections and polls for a valid licence number. The API structure which passes it from the client hasn't been made to work differently.

> > The Borland InterBase network access licence
> > simply allows a larger number of remote clients
> > to log in to the server.
>
>So what you are saying is that the old IB5 (and previous) modular
>licencing no longer exists in the IB6 source code?

I don't know about the IB6 commercial source code; the code fragments still appear to be there on Borland's tree, just not enabled.

> > > Of course if you built your own copy of
> > > Firebird from the source you could probably
> > > take care of this more directly.
> >
> > It's hard to see what this would solve...
>
>**IF** the hooks used by the old licencing system still exist in the
>IB source code, I should have thought it would be relatively easy to
>compile a version that was local only, that would refuse network
>access.

I don't know about "relatively easy"...the point I was trying to make was that remote access is just remote access. But, sorry, I misinterpreted your comment, I think.

AFAIK, the model is the same as it was with previous IB versions: The server can only discern whether the licence of the user currently trying to connect is past the nth number of current users allowed by *that* user's licence. IOW, if the user's licence key allows 5 users (* four connections) and 5 users are already logged in, this user won't get access. But if another user comes along with an internet licences, s/he will get in.

> > For Firebird, even a remote client licence is
> > unnecessary. If the server is running on your
> > machine and other people who have SYSDBA privileges
> > can access it, you can't keep them out.
>
>You can with a firewall product like ZoneAlarm. I dont want to get
>too far off-topic, but in many situations it is highly appropriate to
>use a third party product to solve these types of situations. If
>security is really a concern then indirect attacks also need to be
>considered. Third party products can provide protection against
>indirect forms of intrusion.

I agree. Licensing wasn't designed to protect the security of the database, it was designed to provide the proprietor of the software with an ongoing source of revenue. It's a common misconception that database engines are obliged to provide security from intruders, as if "security" were just one simple feature that a database either has or has not. Those who buy certain RDBMS because of its security features are just deluding themselves. Database security is an expensive and complicated business problem in its own right and, to a significant degree, is dependent on the security of the operating system and/or the NOS.

Firebird has on its agenda future design changes to facilitate interfaces with plug-in security modules, firewalls, et al. It seems to be a better way to go than hard-wiring security features into so-called "secure versions", as other vendors do. A security API, if you will, gives flexibility to the model and provides a range of security levels and choices which can change as requirements change without affecting the engine.

>This is not to say that Firebird should not get the ability to run
>local only. I think that this would be a good feature, but it is one
>that should not be exclusively relied on for high security situations.

The local ibserver model is flawed by the IPC-space "problem" that precludes thread-safety. This affects not only desktop-only deployment but also multi-tier deployments where the application server program depends on multi-threading local connections. It was designed that way - to make it easy to simulate database access during development - but it was in the context of a licensing model that forbade deployment of local IB. Charlie Caro has already stated that the whole local model would have to be re-architected to make it otherwise.

It's not a high priority to make Firebird a deployable desktop-only database. There are database engines around that do desktop better than Firebird. Borland perhaps has different priorities: by marketing their cheaper "desktop edition", they will have to be prepared, seemingly, to confront the multi-threading issue and craft some sort of robustness into the local server architecture.

Now way OT, for which I apologise; and apologies too for misinterpreting what you proposed.

Regards,
Helen

All for Open and Open for All
InterBase Developer Initiative · http://www.interbase2000.org
_______________________________________________________