I support Jim's plan for plug-in modules that implement security. (In
fact, I proposed it myself as a future direction for InterBase a couple
of years ago.)

I think the security modules should be for user authentication and group
identification. Privileges once the user is authenticated to the
database should be controlled by SQL privileges. We should add more
types of privileges as built-ins, compatible with the GRANT/REVOKE
syntax in SQL.

It would be interesting, however, to allow the security plugin to
implement methods to "overload" GRANT/REVOKE, though. I mean that
GRANT/REVOKE would call into the security module to ask permission
before performing the grant or revoke. Modules that didn't need to
control this would just return true always.

As Jim said, there should be nothing schema-specific about a security
plugin.

There are only a finite number of security implementations that would
need to be written. I would suggest that as part of the plugin
implementation, the implementor create one plugin that mimics the
current isc4.gdb based security, and one that uses Kerberos. Those
examples should allow third parties to go off and do plugins to
integrate with NDS, or ADS, or NIS+, or what have you.

I don't think it is unreasonable to require that these plugins be
written in C. For heavens sake, all Netscape browser plugins are
written in C or C++, aren't they? There are hundreds of those! That
should show that it's not that difficult.

I would claim that anyone who is unable to use C to write a plugin has
no business writing an implementation of security anyway. You were
talking about how do you know if a plugin is safe? Well, I would feel a
lot more uncomfortable using a plugin written in VB because that's the
only language the author knows!

Jim Starkey wrote:

> There is no reason that Interbase cannot provide an evolving set
> of authentication/security modules. Making the module loadable
> just means that third parties can offer added value modules without
> requiring that Interbase be built on site (which, incidentally,
> would essential eliminate the ability for ISC-IV or anyone else
> to sell certified kits).

ISC-IV could have a "breaking this seal voids your warranty" policy. If
you load a module that has _not_ been certified by ISC-IV _with_ the
version of the server you're using, then the certification is
invalidated.

I just realized that the new company moniker gives additional meaning to
isc4.gdb. :-)

Bill Karwin