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