|Subject||Re: [Firebird-Architect] External engines - metadata|
> On Friday 19 October 2007 13:21, Vlad Khorsun wrote:Exactly
> > > 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.
> > > But I'm afraid that weEveryone may create database and occupy whole hdd by it. Is it good ?
> > > 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'.
> > Note - one may GRANT CREATE DATABASE TO PUBLIC on the specialSomething like this
> > dedicated engine instance serving this bad legacy applications.
> And turn off unsafe languages in it? That's really good workaround.
> > > Let me point here, that if needed we may easily distinguish betweenNo. Restrict use of CREATE\DECLARE PROCEDURE\FUNCTION LANGUAGE ...
> > > 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?
> For me this restriction is not enough to make use of unsafe external languagesI prefer to not separate safe\unsafe languages. SQL\EXTERNAL is enough for me.
> 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?
And, yes, we may allow to EXECUTE\SELECT any EXTERNAL SP only by SYSDBA
by default (or something like this)