Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Grants overwrite previous rdb$security_classes entries [CORE479] #827

Closed
firebird-issue-importer opened this issue Nov 14, 2000 · 13 comments

Comments

@firebird-issue-importer

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-issue-importer
Copy link
Author

firebird-issue-importer commented Jun 19, 2006

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-issue-importer
Copy link
Author

firebird-issue-importer commented Jun 21, 2006

Modified by: @pcisar

Component: Engine [ 10000 ]

assignee: Dmitry Yemanov [ dimitr ]

SF_ID: 222375 =>

@firebird-issue-importer
Copy link
Author

firebird-issue-importer commented Jul 6, 2006

Modified by: @pcisar

assignee: Dmitry Yemanov [ dimitr ] =>

@firebird-issue-importer
Copy link
Author

firebird-issue-importer commented Jul 16, 2006

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-issue-importer
Copy link
Author

firebird-issue-importer commented Jul 16, 2006

Modified by: @dyemanov

assignee: Claudio Valderrama C. [ robocop ]

@firebird-issue-importer
Copy link
Author

firebird-issue-importer commented Jul 19, 2006

Modified by: @dyemanov

Link: This issue block progress on CORE82 [ CORE82 ]

@firebird-issue-importer
Copy link
Author

firebird-issue-importer commented Dec 19, 2007

Modified by: @dyemanov

Target: 2.5.0 [ 10221 ]

@firebird-issue-importer
Copy link
Author

firebird-issue-importer commented Dec 19, 2007

Modified by: @dyemanov

assignee: Claudio Valderrama C. [ robocop ] =>

@firebird-issue-importer
Copy link
Author

firebird-issue-importer commented Jan 28, 2008

Modified by: @pcisar

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

@firebird-issue-importer
Copy link
Author

firebird-issue-importer commented Feb 15, 2008

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-issue-importer
Copy link
Author

firebird-issue-importer commented Nov 12, 2009

Modified by: @pcisar

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

@firebird-issue-importer
Copy link
Author

firebird-issue-importer commented Jan 19, 2016

Modified by: @pavel-zotov

QA Status: No test

@firebird-issue-importer
Copy link
Author

firebird-issue-importer commented Nov 29, 2016

Modified by: @pavel-zotov

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

QA Status: No test => Done successfully

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants