--- In firebird-support@yahoogroups.com, Aage Johansen <aagjohan@o...>
wrote:

>
> pi3k14 wrote:
> > I would like to make a pledge for backporting this bugfix to v1.

5.x,

> > and at the same time highlight the impact of this bug (also ref.
> > 1343845).
>
> Frode, are you making a plea or a pledge?

:) A plea for others to make a pledge. (Should have checked the
dictionary) btw. I might help with this myself, but I think I would
need a lot of help with finding the correct bits and pieces ...

>
> >
> > _Every_ database restored from a backup is _corrupt_, it will hit

you

> > as strange access problems later on. If you are running a single
> > database this is managable, but if this is a potential problem to

100+

> > of your clients, well ... shit happens :(
>
> For which versions (and under which circumstances) do this happen?

I

> restore 1.5.x backups often without seeing corruption.
>

After restore the generator RDB$SECURITY_CLASS is set to 0, in itself
this is no problem.
The problem occurs when you do a GRANT on something in the database,
that might invalidate other GRANT's (when the new value of
RDB$SECURITY_CLASS correspond to something used in an older GRANT).
So far we have only observed this in SELECT GRANT's that is no longer
valid. Examining the metadata will not show any errors because the
fault is in the binary representation of the access rights.
REVOKE'ing and GRANT'ing the rights one more time will fix the
problem.
But when the problem happens through several levels of procedures and
triggers, it might take some time to find the cause.

frode