Subject | Over privileged database objects |
---|---|
Author | Ann W. Harrison |
Post date | 2004-12-22T17:15:29Z |
This is an expansion of a bug report - The problem
will be fixed in Firebird 2.
Occasionally, Firebird appears to ignore privileges
that are granted, especially privileges granted to
procedures. This bug is present in all versions of
InterBase up to and including V6, possibly later as
well, and in Firebird 1.0.x. It is a particular
problem in Firebird 1.5.x.
If any one object has more than about 2000 privileges
granted on it, the Firebird 1.0.x engine ceases to
recognize some grants, starting with grants to
procedures, then grants to triggers, then grants to
views, and finally grants to users. The Firebird 1.5
engine has an internal overflow which corrupts the
ACL and loses all granted privileges on the object.
The engine implements grants by creating an access
control list (ACL) for each object. The maximum
length of an ACL is 64Kb, which seems like a lot,
but translates to about 2000 distinct grants
depending on the length of the names of the objects
to which the privileges are granted.
A contributing factor is that privileges granted
to procedures, views, and triggers are not removed
automatically when the procedure, view, or trigger
is deleted. The workaround is to removed unneeded
privileges in the RDB$USER_PRIVILEGES table.
Regards,
Ann
will be fixed in Firebird 2.
Occasionally, Firebird appears to ignore privileges
that are granted, especially privileges granted to
procedures. This bug is present in all versions of
InterBase up to and including V6, possibly later as
well, and in Firebird 1.0.x. It is a particular
problem in Firebird 1.5.x.
If any one object has more than about 2000 privileges
granted on it, the Firebird 1.0.x engine ceases to
recognize some grants, starting with grants to
procedures, then grants to triggers, then grants to
views, and finally grants to users. The Firebird 1.5
engine has an internal overflow which corrupts the
ACL and loses all granted privileges on the object.
The engine implements grants by creating an access
control list (ACL) for each object. The maximum
length of an ACL is 64Kb, which seems like a lot,
but translates to about 2000 distinct grants
depending on the length of the names of the objects
to which the privileges are granted.
A contributing factor is that privileges granted
to procedures, views, and triggers are not removed
automatically when the procedure, view, or trigger
is deleted. The workaround is to removed unneeded
privileges in the RDB$USER_PRIVILEGES table.
Regards,
Ann