--- In firebird-support@yahoogroups.com, "Adam" <s3057043@...> wrote:

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

I guess I actually spoke too soon. I am pretty new to the whole
ROLES and rights stuff with DBs. All I had to do (after saying that
my new user was GRANTED and had ADMIN OPTIONS with their ROLE) was
log in to that new user specifying the ROLE I set up for them.
After that I actually do have access to change the RDB$ROLES table
which will let me undo this if I want, and I assume probably also
let me change other system tables. Before I tried this I went in to
the RDB$RELATIONS table and changed the owner of everything to my
new user, so I don't know if this had any impact. I will have to
check that out because it seems kind of dangerous just to go in
there and change the owner so I would like to not do this if
possible.

Does anyone else have any feedback on this change before I barrel on
ahead and change over a 1000 companies systems to this :)

Oh we would love to send those guys the bill if we could. Some of
them have been asking money so they can refund their clients (which
are really our clients too), because the actual clients are mad that
the software doesn't work and want their consultant payments back.
The funny thing is we sell our software in the ballpark of $3,000 I
think and these consultants tack on sometimes upwards of $60,000 on
top of what they paid for the actual software. I don't know what
these guys are smoking that would make them think that we would hand
over $60,000 because they wrecked someones business, but I want
some :)

Thanks to everyone for their help with this.