On Friday 19 October 2007 12:20, Vlad Khorsun wrote:

> > Certainly, we must have well defined user's rights related with defining
> > external routines.
>
> All we can (and must) to do is define and check
> CREATE\DECLARE\ALTER\DROP <object> privileges at database level. All other
> is external to database engine and not an our deal
>
> > Without it we can easily return to problems, when any user
> > with valid FB login may execute any code in context of firebird server.
> > For example, if any user would be able to create database (becoming it's
> > owner)
>
> Here we have a real problem - we must define and check privileges for
> CREATE DATABASE at engine instance level.

Yes, limiting CREATE DATABASE is a possible way to go. But I'm afraid that we
do open a can of worms here. Some legacy application can rely on ability for
any user to create new database. Don't ask me why it's needed, just one
example - program needs to store personal user settings in own database (at
least MS does such a trick with it's registry). Yes, it's possible to rewrite
that application, but to let it work right now CREATE DATABASE is granted to
everyone, and possible results are easy to predict. I.e. I do not like making
security of the system as a whole dependent upon breaking old features that
worked >20 years.

Let me point here, that if needed we may easily distinguish between database
owner and SYSDBA (actually different flags in struct usr). Therefore one more
possible solution - external routines may be defined only by SYSDBA. This may
become a parameter in languages definition file. For example, leagcy PSQL is
completely safe.