Subject | fb1 - grants "inactive" after gbak/restore ? |
---|---|
Author | Alexander Marx |
Post date | 2002-12-12T12:52:51Z |
hi,
we recently migrated all of our interbase6 databases
to firebird 1.0 (classic edition w/ 64bit i/o support)
however, we now have some minor issues with our
backup-skripts (backup/restore from one node to another)
backup and restore finishes without errors, but
the permissions (grant's) on the restored database do
not seem to work.
they are in the database, because a "show grant" prints them,
but connecting to the database as a user (e.g. not as sysdba)
and selecting from one of the tables results in
: data2:/usr/firebird# ./bin/isql data/test.gdb -u snsearch -p <pass>
: Database: data/test.gdb, User: snsearch
: SQL> show grant meldung;
: GRANT DELETE, INSERT, SELECT, UPDATE, REFERENCES ON MELDUNG TO USER SNSEARCH
:
: SQL> select * from meldung;
: Statement failed, SQLCODE = -551
:
: no permission for read/select access to TABLE MELDUNG
: SQL>
the only solution so far has been, revoking all rights
from user snsearch and then re-granting them to user snsearch.
but this is not quite what i expect from a "full-backup".
is this intended or do i miss something here? a bug maybe?
thx,
mad.
we recently migrated all of our interbase6 databases
to firebird 1.0 (classic edition w/ 64bit i/o support)
however, we now have some minor issues with our
backup-skripts (backup/restore from one node to another)
backup and restore finishes without errors, but
the permissions (grant's) on the restored database do
not seem to work.
they are in the database, because a "show grant" prints them,
but connecting to the database as a user (e.g. not as sysdba)
and selecting from one of the tables results in
: data2:/usr/firebird# ./bin/isql data/test.gdb -u snsearch -p <pass>
: Database: data/test.gdb, User: snsearch
: SQL> show grant meldung;
: GRANT DELETE, INSERT, SELECT, UPDATE, REFERENCES ON MELDUNG TO USER SNSEARCH
:
: SQL> select * from meldung;
: Statement failed, SQLCODE = -551
:
: no permission for read/select access to TABLE MELDUNG
: SQL>
the only solution so far has been, revoking all rights
from user snsearch and then re-granting them to user snsearch.
but this is not quite what i expect from a "full-backup".
is this intended or do i miss something here? a bug maybe?
thx,
mad.