|Subject||Re: [Firebird-Architect] External engines - metadata|
> On Friday 19 October 2007 12:20, Vlad Khorsun wrote:Its as "must have" i'd said.
> > > 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 weIf someone want to GRANT CREATE DATABASE TO PUBLIC its not our
> 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.
problem. But normal SQL-secuity is a "must have". It one of the our huge
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 databaseIts may be a solution until we implement normal security
> owner and SYSDBA (actually different flags in struct usr). Therefore one more
> possible solution - external routines may be defined only by SYSDBA.