Incorrect restore of security classes [CORE2214]

[firebird-automations]

Submitted by: @asfernandes

SQL security classes are maintained automatically by changes in RDB$USER_PRIVILEGES. They are not backed up, and are recreated when restoring RDB$USER_PRIVILEGES.

But the problem is that the generator RDB$SECURITY_CLASS is not backed up. When restoring, new security class names are not created because this names (in RDB$RELATION_NAME, RDB$PROCEDURE_NAME and RDB$RELATION_FIELDS) are backed up. So old names are restored, but the generator is not incremented, hence new class names will overlap existing ones.

This issue affects v2.5. It may also affect others versions when using grants for individual fields [grant update (colum_list)], but I'm not very sure.

The solution seems to be not restore RDB$SECURITY_CLASS that starts with SQL$, the reserved prefix for SQL security classes, letting a new name be generated.

Commits: a2fbf5a

[firebird-automations]

Modified by: @asfernandes

assignee: Adriano dos Santos Fernandes [ asfernandes ]

[firebird-automations]

Modified by: @asfernandes

description: SQL security classes are maintained automatically by changes in RDB$USER_PRIVILEGES. They are not backed up, and are recreated when restoring RDB$USER_PRIVILEGES.

But the problem is that the generator RDB$SECURITY_CLASS is not backed up. When restoring, new security class names are not created because this names (in RDB$RELATION_NAME, RDB$PROCEDURE_NAME and RDB$RELATION_FIELDS) are backed up. So old names are restored, but the generator is not incremented, hence new class names will overlap existing ones.

This issue affects v2.5. It may also affect others versions when using grants for individual fields [grant update (colum_list)], but I'm not very sure.

The solution seems to be not restore RDB$SECURITY_CLASS that starts with SQL$, the reserved prefix for SQL security classes.

=>

SQL security classes are maintained automatically by changes in RDB$USER_PRIVILEGES. They are not backed up, and are recreated when restoring RDB$USER_PRIVILEGES.

But the problem is that the generator RDB$SECURITY_CLASS is not backed up. When restoring, new security class names are not created because this names (in RDB$RELATION_NAME, RDB$PROCEDURE_NAME and RDB$RELATION_FIELDS) are backed up. So old names are restored, but the generator is not incremented, hence new class names will overlap existing ones.

This issue affects v2.5. It may also affect others versions when using grants for individual fields [grant update (colum_list)], but I'm not very sure.

The solution seems to be not restore RDB$SECURITY_CLASS that starts with SQL$, the reserved prefix for SQL security classes, letting a new name be generated.

[firebird-automations]

Modified by: @asfernandes

status: Open [ 1 ] => Resolved [ 5 ]

resolution: Fixed [ 1 ]

Fix Version: 2.5 Beta 1 [ 10251 ]

[firebird-automations]

Modified by: @pcisar

status: Resolved [ 5 ] => Closed [ 6 ]

[firebird-automations]

Commented by: @hvlad

> The solution seems to be not restore RDB$SECURITY_CLASS that starts with SQL$, the reserved prefix for SQL security classes, letting a new name be generated.

There was user reports about not possible to downgrade database in ODS11.2 to ODS 11.1 because of issues with security classes.
Could it be related with this fix ?

[firebird-automations]

Modified by: @pavel-zotov

QA Status: No test