Hi Helen,

> At 11:17 AM 12/06/2007, MRF wrote:
>
>>I must admit - it would be nice for us to be able to connect to a
>> Firebird
>>Server and ask "what database files do you know about that I have
>>permission to use?" without a registration overhead - using the existing
>>aliases.conf entries.

Let me rephrase: "What database files do you know about - that I am
allowed to know about" or "have permission to try and connect to".

>
> That information doesn't exist anywhere...given that user
> authentication occurs at server level. Even if the server had some
> utility routine whereby it could read through aliases.conf (which is
> nothing but a text file), there's nothing about a database header
> that the server could visit and read and say "UserX has (or has not)
> permission to use this database".

Our current service is simpler than this - it just returns a list of
aliases a 'user name' is allowed to know about (stepping up to an
authenticated user name would be a nice enhancement). Adam's suggestions
about using security.fdb or .ini style sections in aliases.conf would work
for us.

In fact we use prefixes - which, although requiring duplicate entries in
aliases.conf, seems to work well 'in the wild'. The only security is that
we strip the prefix & re-append it - so writing down the returned alias
name doesn't work outside our service/application.

Re Adam's 'default security' concern - for us acces is 'turned off' by
default - simply by having no valid entries - admins have to deliberately
make an alias accessible - 'standard' aliases continue to work unimpeded.

>
> If the user gets past server authentication then any connection
> request will succeed. Once the connection exists, the user's access
> to *that* database depends entirely on his/her SQL permissions.

This is OK with us - our model isn't about database authentication - only
about access to aliases - so it's possible to 'know about' the alias - but
not have 'access to' the database (an admin issue in practice).

>
> Other authentication models exist, of course, and in Firebird 3
> you'll be able to mix and match permissions at several levels
> according to requirements. I have no idea at this point how (or if)
> that would translate to satisfy the kind of inquiry you stated above.

The Firebird 3 authentication model will have value for us - but is a
separate thing from our 'list of aliases' use. I don't know enough about
the engine to understand whether the authentication changes to the
Firebird 3 would help, or hinder, getting a 'list of aliases' from
Firebird itself.

Since roles are kept at database level I assume it would complicate admin
unduly to use roles for this - even though the engine should know the role
that is connecting - similarly, I assume, basing it on user name only
would straight-jacket functionality... Here I run out of knowledge - I'm
at the level of a user-story - rather than a use-case - for a generic
implementation.

hth Max