> If an LDAP like system (or an LDAP implementation) were embedded in
> the Firebird engine, then the performance degradation would be
> limited.

The main question is how the permissions are determined during request
execution. Currently this is performed during statement compilation
and it seems that moving permission checks to the execution time
without degrading the performance is not an easy task.

> The authorization does not have to be implemented at the crude level
> of querying on every statement. RACF, for example, ties all of the
> authorizations to the user session at connect time. When you
> disconnect and reconnect, you get your new authorities. It would
> increase the memory requirements of a connection, and the time to
> connect/disconnect, but it does not have to impact every statement.

Then please define what the "authority" in this case is.

SQL defines a concept of "role" to which the permissions on different
database objects are granted. There was a suggestion to introduce the
concept of a "group" with similar capabilities to the role. The main
difference would be that within a session user can belong to one role
but to multiple groups. Jim suggested to add a possibility to switch
the role within one session as a nice feature to support application
servers.

How would the authorization look in your case? Would admin be required
to define permissions for each database object in LDAP (e.g.
permission to select from some table)? Or would it go in the direction
of role or group, where actual grants are stored in the database? If
former, does this concept really belong to the LDAP? If latter - isn't
it part of the PAM concept (sorry, I actually know only JAAS - there
it is)?

Roman