Thanks Helen.
I think the problem is not this one.
As an error, the system report that the user has no access privilege to some
system tables (RDB$RELATIONS, RDB$RELATION_FIELDS, etc.), even though ther
was no change in privileges.

Now I have deleted and recreated the same user, but the problem persist.
This user have never has access privileges to system objects.

Any help, please?

Ramiro

>
> 2009/10/21 Helen Borrie <helebor@...>
>
>
>>
>> At 12:54 AM 22/10/2009, Ramiro Barreca wrote:
>> >We are having problems with rights acces to several tables, users and
>> roles.
>> >The FB server reports that a user does not have read access to a table
>> even
>> >though it has
>> >We have tested rights the same on user own rigths and its roles using
>> >IBExpert and everithing is granted, but the system continues reporting
>> >access errors.
>> >May be the security2.fdb database gets corrupted?
>>
>> Not the security database: it has no part to play in permissions.
>>
>>
>> >There was no change in security issues to those users/roles and today the
>> >problem appeared.
>> >Any help, please?
>>
>> Probably symptoms of an old bug that shows up when the number of
>> permissions in RDB$USER_PRIVILEGES gets too big.
>>
>> Look at http://tracker.firebirdsql.org/browse/CORE-216 and
>> http://tracker.firebirdsql.org/browse/CORE-1957
>>
>> That is why DS asked you about your exact Firebird version. These bugs are
>> fixed in Fb 2.1.2/2.1.3 and 2.0.5 (FB 1.5.6 also).
>>
>> > If so, any way to validate this database?
>>
>> If this bug is the cause of your problems then the Access Control List is
>> already broken (truncated).
>>
>> As a temporary workaround, you could try reducing the size of the ACL. Get
>> everybody off the system while you do this.
>>
>> As SYSDBA, do a metadata extract (isql -a), piped to a text file. At the
>> end of the output is a full list of the GRANT/REVOKE statements that pertain
>> to the records in RDB$USER_PRIVILEGES. Use that to identify any unused
>> permissions (for users, tables, other objects that no longer exist) and to
>> write a script to revoke those dead privileges. That should update the ACL
>> with a progressively smaller size.
>>
>> If you continue to add privileges then the problem will keep coming back
>> until you upgrade to the repaired server version. Of course, if there are no
>> dead privileges that you can clean out then there is no temporary
>> workaround.
>>
>> ./heLen
>>
>>
>>
>
>
>
> --
> Ramiro Barreca
> rbarreca@...
>

--
Ramiro Barreca
rbarreca@...


[Non-text portions of this message have been removed]