--- In firebird-support@yahoogroups.com, "dbagregc" <gcobb@...> wrote:

>
> --- In firebird-support@yahoogroups.com, Radu Sky <skysword76@>
> wrote:
> >
> > dbagregc wrote:
> > > --- In firebird-support@yahoogroups.com, Alexandre Benson Smith
> > > <iblist@> wrote:
> > >> dbagregc wrote:
> > >>> I tried to create a role called sysdba and it would not let me
> > > do
> > >>> it. It says "This operation is not defined for system tables.
> > >>> unsuccessful metadata update. user name SYSDBA could not be
> > > used
> > >>> for SQL role." The steps I took were to log on as sysdba,
> > > create a
> > >>> new user, log on as the new user, then tried to create role
> > > called
> > >>> sysdba. Any suggestions?
> > >>>
> > >> I think it should be:
> > >>
> > >> Log as SYSDBA
> > >> create the SYSDBA role
> > >> logout
> > >> try to log as SYSDBA (should fail)
> > >>
> > >> never tried it, but I think that should be this way.
> > >>
> > >>
> > >> see you !
> > >>
> > >> --
> > >> Alexandre Benson Smith
> > >> Development
> > >> THOR Software e Comercial Ltda
> > >> Santo Andre - Sao Paulo - Brazil
> > >> www.thorsoftware.com.br
> > >>
> > >
> > > I tried this and it did not work either. It could be the fact
> that
> > > I am doing this through IBExpert, but I would assume that it has
> the
> > > same functionality that you get from talking to the database
> through
> > > ODBC and the firebird utils.
> > >
> >
> > Create some role.
> > Modify RDB$ROLES, rename your role to SYSDBA
> >
> > HTH
> > Radu
> >
>
> Ok, modifying does actually appear to work (to some extent). It
> will let you do this, but I have found a problem with this that may
> be unfixable. It appears that you can not edit system tables
> (RDB$SOMETABLENAME) unless you are SYSDBA. Is this correct? In the
> past we had made a few modifications to fields by editing the system
> tables. I didn't really want to give up this ability unless
> absolutely necessary. Maybe even more importantly though is the
> fact that the "hack" to get this done is to modify the system table
> RDB$ROLES. What if we find out some time down the road that this
> process doesn't really work for us and we want to enable the SYSDBA
> user again. The new user cannot edit the RDB$ROLES table. I have
> tried granting the new user (actually the role the new user is
> using) rights to the system tables, but once I do this and try to
> log back in to the database I get all kinds of errors and can never
> log in as that user again (if this was your only user and you did
> this after locking out sysdba then you can never get in to the
> database again). So if a user doesnt normally have access to the
> system tables and you can't grant them access to them, how do I edit
> system tables? I guess what I want is to be able to create a
> user/role that has all the same rights as SYSDBA so we can do
> everything we can do now, but have the ability to keep people from
> messing with the database.
>
> I guess your solution does work, but it just scares me to do
> something that I can not undo, which also restricts me from doing
> things I used to be able to do.
>

Are you able to fix it as the owner user of the database (assuming the
owner is not SYSDBA). Sending your consultants the bill for the
support should teach them quick smart not to mess around ;)

Perhaps also find out what they are attempting to achieve and give
them a script to do that will be less work for all.

As far as locking down goes, Geoff Worboys has a nice paper on the
firebirdsql.org site, and I have put my experiences on the fbtalk site.

Adam