Issue Details (XML | Word | Printable)

Key: CORE-216
Type: Bug Bug
Status: Resolved Resolved
Resolution: Fixed
Priority: Major Major
Assignee: Alexander Peshkov
Reporter: Ann Harrison
Votes: 3
Watchers: 1
Operations

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

too many grants lose privileges

Created: 22/Dec/04 12:00 AM   Updated: 03/Dec/08 10:10 AM
Return to search
Component/s: Engine
Affects Version/s: None
Fix Version/s: 2.5 Beta 1

Time Tracking:
Not Specified

Issue Links:
Relate
 

SF_ID: 1089861


 Description  « Hide
SFID: 1089861#
Submitted By: awharrison

Issuing more than 2000 grants on any one object causes
an internal buffer flow in generating the access
control list that actually enforces the rights.

GRANT INSERT ON MY_TABLE TO TRIGGER T1;
GRANT INSERT ON MY_TABLE TO TRIGGER T2;
GRANT INSERT ON MY_TABLE TO TRIGGER T3;
...
GRANT INSERT ON MY_TABLE TO TRIGGER T2201;

All the grants are on the same object - in this case a
table and are given to differen entities, in this case,
2201 different triggers. Duplicate grants don't count
in the total.

In Firebird 1.0.x, some grants will not be recognized
at runtime. Grants to procedures disappear first, then
triggers, views, and finally users.

In Firebird 1.5.x, the acl is corrupted and no access
rights are recognized.

The problem normally arises because rights granted to
triggers, views, and procedures are not removed when
the triggers, views, or procedures are deleted.

The workaround is to manually remove obsolete records
from RDB$USER_PRIVILEGES until the total number of
grants on any one object is less than 1900. The actual
restriction is that the size of the ACL must be less
than 64Kb, where each ACL consists of the name of the
object to which the grant is made and a grant type,
grantee type, and some other bytes.

 All   Comments   Work Log   Change History   Version Control      Sort Order: Ascending order - Click to sort in descending order
The cvs commits can not be displayed for repository Firebird at the moment since the log has not yet been parsed. The log will be parsed the next time the VcsService runs. If you have administrators privileges you can hasten the next time the service will run in the service section of the Administration pages.