Grants overwrite previous rdb$security_classes entries [CORE479]

[firebird-automations]

Submitted by: Claudio Valderrama C. (robocop)

Block progress on CORE82

Votes: 1

SFID: 222375#⁠
Submitted By: robocop

First, let me say that a clarification is need. If Firebird can rely solely on rdb$user_privileges, then this report is not critical. Otherwise, the results of records being overwritten silently on rdb$security_classes is an issue. The following is an almost unedited copy from an article I wrote on the NG:

- Create a table with 31-byte name.
- Create a second table with the same name, except that it differs only in the last, 31th character.
- Grant permissions to userA on the first table and to userB on the second table.
- Go to see rdb$user_privileges and you'll see your entries as they should be.
- Go to rdb$security_classes: with rdb$ as a prefix, 31-4=27, oh what a brilliant person I am.
Here's your 27-byte limitation: what happened to this
table? Both entries were mapped to the same record, same security class! As a result of that, the second GRANT overwrote the information for the first one, because rdb$security_classes.rdb$security_class used
sql$<table_name>
hence the last 4 bytes were ignored. Feature? Undocumented limitation? Bug?

So, what LangRef says could be refurbished as:
<Some objects, such as security class names, are restricted in practice to 27 bytes in length.>

The final part comes from Ivan Prenosil:

Or perhaps something like

I shortly played with these things and found out that
-when creating new table, two entries are inserted into rdb$security_classes, one SQL$tab_name, one SQL$DEFAULTx.
-so I tried to create new table with name DEFAULT1 and it overwrote already existing row in rdb$security_classes;
I do not know what exact consequencies it will cause though.

C. (On behalf of Ivan, too.)

Commits: a37aa2f

[firebird-automations]

Modified by: Alice F. Bird (firebirds)

description: SFID: 222375#⁠
Submitted By: robocop

First, let me say that a clarification is need. If Firebird can rely solely on rdb$user_privileges, then this report is not critical. Otherwise, the results of records being overwritten silently on rdb$security_classes is an issue. The following is an almost unedited copy from an article I wrote on the NG:

- Create a table with 31-byte name.
- Create a second table with the same name, except that it differs only in the last, 31th character.
- Grant permissions to userA on the first table and to userB on the second table.
- Go to see rdb$user_privileges and you'll see your entries as they should be.
- Go to rdb$security_classes: with rdb$ as a prefix, 31-4=27, oh what a brilliant person I am.
Here's your 27-byte limitation: what happened to this
table? Both entries were mapped to the same record, same security class! As a result of that, the second GRANT overwrote the information for the first one, because rdb$security_classes.rdb$security_class used
sql$<table_name>
hence the last 4 bytes were ignored. Feature? Undocumented limitation? Bug?

So, what LangRef says could be refurbished as:
<Some objects, such as security class names, are restricted in practice to 27 bytes in length.>

The final part comes from Ivan Prenosil:

Or perhaps something like
<Table names should not exceed 27 bytes, otherwise you can expect problems with privileges....>

I shortly played with these things and found out that
-when creating new table, two entries are inserted into rdb$security_classes, one SQL$tab_name, one SQL$DEFAULTx.
-so I tried to create new table with name DEFAULT1 and it overwrote already existing row in rdb$security_classes;
I do not know what exact consequencies it will cause though.

C. (On behalf of Ivan, too.)

=>

SFID: 222375#⁠
Submitted By: robocop

First, let me say that a clarification is need. If Firebird can rely solely on rdb$user_privileges, then this report is not critical. Otherwise, the results of records being overwritten silently on rdb$security_classes is an issue. The following is an almost unedited copy from an article I wrote on the NG:

- Create a table with 31-byte name.
- Create a second table with the same name, except that it differs only in the last, 31th character.
- Grant permissions to userA on the first table and to userB on the second table.
- Go to see rdb$user_privileges and you'll see your entries as they should be.
- Go to rdb$security_classes: with rdb$ as a prefix, 31-4=27, oh what a brilliant person I am.
Here's your 27-byte limitation: what happened to this
table? Both entries were mapped to the same record, same security class! As a result of that, the second GRANT overwrote the information for the first one, because rdb$security_classes.rdb$security_class used
sql$<table_name>
hence the last 4 bytes were ignored. Feature? Undocumented limitation? Bug?

So, what LangRef says could be refurbished as:
<Some objects, such as security class names, are restricted in practice to 27 bytes in length.>

The final part comes from Ivan Prenosil:

Or perhaps something like

I shortly played with these things and found out that
-when creating new table, two entries are inserted into rdb$security_classes, one SQL$tab_name, one SQL$DEFAULTx.
-so I tried to create new table with name DEFAULT1 and it overwrote already existing row in rdb$security_classes;
I do not know what exact consequencies it will cause though.

C. (On behalf of Ivan, too.)

[firebird-automations]

Modified by: @pcisar

Component: Engine [ 10000 ]

assignee: Dmitry Yemanov [ dimitr ]

SF_ID: 222375 =>

[firebird-automations]

Modified by: @pcisar

assignee: Dmitry Yemanov [ dimitr ] =>

[firebird-automations]

Commented by: @dyemanov

Claudio, I'd like you to investigate possible solutions for this issue. I think we could simply use a system generator for naming the security classes. IIRC, the only dependency on the concatenated name exists in one of the system triggers.

[firebird-automations]

Modified by: @dyemanov

assignee: Claudio Valderrama C. [ robocop ]

[firebird-automations]

Modified by: @dyemanov

Link: This issue block progress on CORE82 [ CORE82 ]

[firebird-automations]

Modified by: @dyemanov

Target: 2.5.0 [ 10221 ]

[firebird-automations]

Modified by: @dyemanov

assignee: Claudio Valderrama C. [ robocop ] =>

[firebird-automations]

Modified by: @pcisar

Workflow: jira [ 10503 ] => Firebird [ 14805 ]

[firebird-automations]

Modified by: @asfernandes

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

resolution: Fixed [ 1 ]

Fix Version: 2.5 Alpha 1 [ 10224 ]

assignee: Adriano dos Santos Fernandes [ asfernandes ]

[firebird-automations]

Modified by: @pcisar

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

[firebird-automations]

Modified by: @pavel-zotov

QA Status: No test

[firebird-automations]

Modified by: @pavel-zotov

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

QA Status: No test => Done successfully