Subject | Re: Can we "Lock Down" Firebird to keep users from tampering with data? |
---|---|
Author | dbagregc |
Post date | 2006-03-14T00:55:01Z |
--- In firebird-support@yahoogroups.com, Radu Sky <skysword76@...>
wrote:
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.
wrote:
>that
> 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
> > I am doing this through IBExpert, but I would assume that it hasthe
> > same functionality that you get from talking to the databasethrough
> > ODBC and the firebird utils.Ok, modifying does actually appear to work (to some extent). It
> >
>
> Create some role.
> Modify RDB$ROLES, rename your role to SYSDBA
>
> HTH
> Radu
>
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.