Issue Details (XML | Word | Printable)

Key: CORE-479
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Adriano dos Santos Fernandes
Reporter: Claudio Valderrama C.
Votes: 1
Watchers: 0

If you were logged in you would be able to see more operations.
Firebird Core

Grants overwrite previous rdb$security_classes entries

Created: 14/Nov/00 12:00 AM   Updated: 29/Nov/16 05:15 PM
Component/s: Engine
Affects Version/s: None
Fix Version/s: 2.5 Alpha 1

Issue Links:

SF_ID: 222375
Target: 2.5.0
QA Status: Done successfully

 Description  « Hide
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
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.)

 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Dmitry Yemanov added a comment - 16/Jul/06 07:43 PM
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.