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.)