> Presumably, someone with enough implicit privilege to create a database

has

> enough implicit privilege to access aliases.conf. No? It should be a
> no-brainer to write a little utility to add a record to aliases.conf

before

> the CREATE DATABASE statement is submitted.

Uh, they're on separate machines. I have multiple developers needing to
create databases. They don't have access to the database server itself. But,
I think this is moot - the FB team will be, at some point in the future,
providing the ability to create a database without them knowing where the
database gets created physically.

> Currently, the firebird.conf parameter DatabaseAccess with RESTRICT
> restricts creation of/access to databases to the directory trees named (it

> can be a semicolon-separated list). There's a feature request on the
> drawing board for Fb 2 to make the first root in the list to be the

default

> database directory.

Sounds good to me. Thanks.

> That depends on the platform, of course. No, the server does not have to
> restart to pick up a new alias. (You're thinking of firebird.conf).

Cool - that's good information to know.

> However, there's [almost] unanimous agreement that it would be useful to
> extend DatabaseAccess = RESTRICT so that the engine can assume a
> default. *That* is a perfectly reasonable extension of RESTRICT
> protection. It's still going to be up to the SysAdmin to implement the
> appropriate filesystem privileges for the Firebird process owner.

Sounds perfect.

> There's more coming in Fb 3, via Vulcan's new plug-in access features. I
> don't have a fine analysis available, nor a crystal ball to predict how
> exactly the Fb 3 implementation will be done. The plan is to allow for
> multiple layers of access, as finely-grained as it needs to be, starting
> from the connecting IP address and filtering down to configured "legal"
> directory locations.

Thank-you very much Helen.