Jim,

> >One approach to get around the unsatisfying feeling could to consider
> >FB$Users as having the _minimum_ information required/expected to be
> >provided by all security approaches. Since the engine needs some

basic

> >information from which security needs to 'hang'.
> >
> Sean, what does the security plugin that emulates the current

semantics

> do? Do it replicate FB$USERS from the security database? Does it try
> to intercept references to FB$USERS and redirect to the security
> database? Replication, of course, is impossible for a readonly
> database. The redirection, on the other hand, would be massively
> complicated to implement, requiring a very "rich" security plugin API.

Well that brings up a good question: What calls is a security plug-in
responsible for?

- Authenticating Users?
- Providing User Information (i.e. Name)?
- Adding/Updating User Information in FB$User table?
- Providing User's SQL Role on connection (i.e. overriding the value
provided in the connection 'string')?
- Providing User's list of Security Groups on connection? (this is a new
thing I'd like -- groups in addition to roles -- but that is another
discussion)

To my mind, the answer to all these questions is: Yes.

> What about users authenticated with PAM, LDAP, or NT Domain? Do they
> get replicated? On first reference? Again, what about readonly
> databases?

I'm not sure about other database engines but my initial reaction would
be that (for read-only databases) unless you're already defined, you get
no access.

What happens because the user information can't be updated? That could a
setting in the plug-in config.


Sean