Issue Details (XML | Word | Printable)

Key: CORE-3133
Type: Bug Bug
Status: Open Open
Priority: Critical Critical
Assignee: Unassigned
Reporter: Alan Braga
Votes: 0
Watchers: 3

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

User has a record on Permission table but firebird doesn't allow the update

Created: 10/Sep/10 07:29 PM   Updated: 14/Sep/10 06:08 PM
Component/s: Security
Affects Version/s: 1.5.6, 2.5 RC2, 2.5 RC3
Fix Version/s: None

File Attachments: 1. File rfunc.rar (46 kB)

Environment: Windows 7 or Windows 2003 Server R2 Standard Edition Service Pack 2. Intel Xeon E5430 / X3220, 4GB RAM MEMORY

 Description  « Hide

We use the users and privileges from Firebird and we are facing the following problem:
Sometimes the user has the privilege to update a field but firebird throw a message which says the user doesn't have it.

You can download a database sample from here:

Connect to the database as LUCICELIA and try the following command:
The error message is going to be: "This user does not have privilege to perform this operation on this object.
no privilege for update/write access to COLUMN SPR_RI.RI_STATUS"

if you use the query: "SELECT * FROM RDB$USER_PRIVILEGES U WHERE U.RDB$USER = 'LUCICELIA' and u.RDB$RELATION_NAME = 'SPR_RI'; there is a record for this field.

If we delete this record and use the grant command again, the user still doesn't have the privilege to update the field.

The only way to correct this is backing up and restoring the database, but this is happening frequently and we can't do this all the time.
This already happened on firebird 1.5.x and we are trying the 2.5 now but the error still occurring

 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Helen Borrie added a comment - 10/Sep/10 09:01 PM
Shouldn't your test be as follows?


Alan Braga added a comment - 11/Sep/10 01:11 AM
This user has permission to all the fields on table SPR_ITEM (RDB$FIELD_NAME = null)

There is a trigger on SPR_ITEM that update SPR_RI and lots of other things

Adriano dos Santos Fernandes added a comment - 11/Sep/10 04:11 PM
I was going to test, but found your database full of UDFs that I don't have.

Can't you create minimal possible test case?

Alan Braga added a comment - 13/Sep/10 11:18 AM
UDF for the database

Alan Braga added a comment - 13/Sep/10 11:25 AM
Sorry I had forgot the UDF. I attached here.

Unfortunately I don't know how to create the problem and it happens frequently in some of our clients. I can send you another database but the size and the structure is almost the same.

Thank you Helen and Adriano for the support

Adriano dos Santos Fernandes added a comment - 14/Sep/10 06:08 PM
The problem is that RDB$RELATIONS.RDB$RUNTIME is not correctly maintained for columns security classes, because these grants don't schedules a relation format change.

When a column security class is missing in RDB$RUNTIME, its got from RDB$RELATIONS.RDB$DEFAULT_CLASS. That is not correct.

As soon a backup is restored, RDB$RUNTIME is recreated and everything works as desired.