Issue Details (XML | Word | Printable)

Key: CORE-1957
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Alexander Peshkov
Reporter: Alexander Peshkov
Votes: 1
Watchers: 2
Operations

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

Long ACLs truncated

Created: 24/Jun/08 05:06 AM   Updated: 26/Jan/09 09:43 AM
Component/s: Engine, Security
Affects Version/s: 1.0.3, 2.0.0, 1.5.4, 2.0.1, 2.1 Alpha 1, 2.1 Beta 1, 2.0.2, 2.0.3, 2.1 Beta 2, 1.5.5, 2.1 RC1, 2.5 Initial, 2.1 RC2, 2.1.0, 2.0.4, 2.5 Alpha 1, 2.1.1
Fix Version/s: 2.0.5, 2.1.2, 2.5 Beta 1, 1.5.6

Time Tracking:
Not Specified

Environment: Any
Issue Links:
Relate

Planning Status: Unspecified


 Description  « Hide
This was reported to me privately by Paul Beach.

The grant.epp code turns out to have a couple of bugs that
interact badly with ib_replicator. The replicator grants
privileges on the replication log table to triggers it
generates for each table to be replicated. The result is
long ACLs - both lots of entries and relatively long (>20
character) names.

The original bug, present in all versions of Firebird
is in save_security_class:

  blob = BLB_create(tdbb, dbb->dbb_sys_trans, (BID)&blob_id);
  BLB_put_segment(tdbb, blob, buffer, length);
  BLB_close(tdbb, blob);

BLB_put_segment takes an unsigned short for the length. As a
result, the ACL is limited to 64Kb, or about 2600 entries if
the average user name is about 20 bytes. An ACL is stored
in order by the type of object being granted rights - people,
then views, then triggers, procedures, and finally roles,
with lots of other stuff (uid, gid, node id) scattered around
for historical accuracy. What that means is that a GRANT ALL
TO PUBLIC will ordinarily fix all grant problems.

The code that builds the ACL originally used the normal pool
allocation mechanism which uses a ULONG to describe the amount
of memory it wants. In version 1.5 ACL is stored in the string class.
That class has a unsigned short length, also limiting ACL's length.

 All   Comments   Work Log   Change History   Version Control   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Dmitry Yemanov added a comment - 24/Jun/08 05:09 AM
Isn't it the same as CORE-216?

Alexander Peshkov added a comment - 24/Jun/08 05:16 AM
Very possible, but I've never seen it.
I've assigned it also to me, looks like will close both when fixed.

Alexander Peshkov added a comment - 24/Jun/08 07:17 AM
Correction - selected first in wrong box

Dmitry Yemanov added a comment - 09/Sep/08 11:52 AM
Is this going to be backported into 1.5.6 and 2.0.5, as intended originally?

Alexander Peshkov added a comment - 28/Oct/08 12:16 PM
Now ported to all 4 supported branches.