> 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.

Its as "must have" i'd said.

> 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.

If someone want to GRANT CREATE DATABASE TO PUBLIC its not our
problem. But normal SQL-secuity is a "must have". It one of the our huge
weakness.

Note - one may GRANT CREATE DATABASE TO PUBLIC on the special
dedicated engine instance serving this bad legacy applications.

> 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.

Its may be a solution until we implement normal security

Regards,
Vlad