> On Friday 19 October 2007 13:21, Vlad Khorsun wrote:
> > > Yes, limiting CREATE DATABASE is a possible way to go.
> >
> > Its as "must have" i'd said.
>
> I'm agreed that limiting right to CREATE DATABASE is useful feature. I do not
> know, on the other hand, how should it be implemented for non-security DB
> based auth, but this is out of 'External engines' scope.

Exactly

> > > 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.
>
> With abiliy to restrict locations of databases using firebird.conf I do not
> treat miss of special 'CREATE DATABASE' grant as extra-ordinary security
> risk. As long as 'CREATE DATABASE' does not mean 'execute arbitrary code'.

Everyone may create database and occupy whole hdd by it. Is it good ?

> > Note - one may GRANT CREATE DATABASE TO PUBLIC on the special
> > dedicated engine instance serving this bad legacy applications.
>
> And turn off unsafe languages in it? That's really good workaround.

Something like this

> > > 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
>
> You mean restrict use if CREATE DATABASE?

No. Restrict use of CREATE\DECLARE PROCEDURE\FUNCTION LANGUAGE ...

> For me this restriction is not enough to make use of unsafe external languages
> safe. I already preview security advisory - granting user CREATE DATABASE
> right in fb 2.5 makes it possible for him to execute arbitrary code. May be
> better automatically turn off unsafe languages for non-SYSDBA?

I prefer to not separate safe\unsafe languages. SQL\EXTERNAL is enough for me.
And, yes, we may allow to EXECUTE\SELECT any EXTERNAL SP only by SYSDBA
by default (or something like this)

Regards,
Vlad