After granting system privilege USE_GBAK_UTILITY to a role, they still can't use gbak.

[nickolasdeluca]

Firebird version: 4.0.4.3010.

Steps to reproduce:
1 - Created a user called backup.
2 - Created a role called BACKUP_ROLE using this command:

CREATE ROLE BACKUP_ROLE SET SYSTEM PRIVILEGES TO USE_GBAK_UTILITY;

3 - Granted the user backup the role of BACKUP_ROLE
4 - Tried to use gbak with the backup user

Got this message:

C:\Program Files\Firebird\Firebird_4_0>gbak.exe -b -user backup -password "MYPW" "MYDBPATH.FDB" "MYFBKPATH.FBK"
gbak: ERROR:Unable to perform operation
gbak: ERROR:    System privilege USE_GBAK_UTILITY is missing
gbak:Exiting before completion due to errors

The password, the database path and fbk path were redacted because of obvious reasons but they were correctly typed, I double checked

What am I supposed to do to allow my user backup to perform gbak backups and restores?

[hvlad]

Pass role to gbak, using ROLE switch

[AlexPeshkoff]

Also you may grant default role to user, it will be always active.

[mrotteveel]

To clarify the other two replies, unless the role is granted as a default role (a feature introduced in Firebird 4.0), a role is not automatically used; it only applies when you explicitly specify it when connecting.

[nickolasdeluca]

Thank you for the suggestion, granting the default role it makes it a lot easier for the backup team when running the command, since they only have to change the user and password on their batch script.

[mrotteveel]

I converted the issue to a discussion, as it is not a bug. For questions, either use firebird-support, or the GitHub Discussions.

[nickolasdeluca]

I tried your suggestion, specifying the ROLE when connecting.

gbak.exe -b -user backup -password "MYPW" "MYDBPATH.FDB" "MYFBKPATH.FBK" -ROLE BACKUP_ROLE

And it looks like it worked, but I got this message:

gbak: ERROR:no permission for USAGE access to GENERATOR MY_GENERATOR_NAME
gbak: ERROR:    Effective user is BACKUP
gbak:Exiting before completion due to errors

Any idea how to proceed? I thought that giving the USE_GBAK_UTILITY meant that this user would not have problems with permission when using GBAK.

[nickolasdeluca]

I did notice though that this generator is different from the others, since the PUBLIC option on it's grant page is not enabled.
When enabling it, the issue goes away. Is there an option to give a system privilege to this role where it can have access to generators?

[mrotteveel]

Well, you could grant ACCESS_ANY_OBJECT_IN_DATABASE, but that might convey too much authority to the backup user.

[nickolasdeluca]

Would this grant allow the user to access the database's tables and run queries on it?

[mrotteveel]

Yes, and update, insert and delete data.

[mrotteveel]

@AlexPeshkoff Is this the intended behaviour, that you still need sufficient "normal" access privileges even if you have USE_GBAK_UTILITY?

[AlexPeshkoff]

On 10/31/24 15:07, Mark Rotteveel wrote: @AlexPeshkoff <https://github.com/AlexPeshkoff> Is this the intended behaviour, that you still need sufficient "normal" access privileges even if you have |USE_GBAK_UTILITY|?

Yes. System privileges are minimal pieces of additional rights check. Most of them match exactly single place of superuser() check in the code. It's OK to combine them into roles oriented on execution of superuser tasks. From README.ddl.txt: System privileges make it possible to delegate part of DBO rights to other users. Pay attention that system privileges provide very thin level of control, therefore sometimes you will need to give user >1 privilege to perform some task (for example add IGNORE_DB_TRIGGERS to USE_GSTAT_UTILITY cause gstat wants to ignore database triggers).

[nickolasdeluca]

Although I understand everything you guys said, I would argue that USE_GBAK_UTILITY should allow a user to perform a full database backup without having to give them full permission to modify every single object in the database.

Isn't GBAK's sole purpose to perform such tasks? if a user is allowed to use it, it means that the DBA is granting them permission to perform such tasks. It's like giving someone permission to open a box, look inside of it, rearrange the content if necessary but not giving them permission to put, take or modify anything inside of it.

[AlexPeshkoff]

On 10/31/24 15:00, Nickolas de Luca Alberton wrote: Would this grant allow the user to access the database's tables and run queries on it?

This grant is absolutely required for gbak to work - w/o it utility can not query data to be backed up.

Yes, and update, insert and delete data.

@mark: This made me surprised. The problem is with USAGE grant, which controls access to generators and exceptions and is currently included into ACCESS_ANY_OBJECT_IN_DATABASE privilege. I wonder - may be it must go into SELECT_ANY_OBJECT_IN_DATABASE too?

[mrotteveel]

Technically the grant to ACCESS_ANY_OBJECT_IN_DATABASE is not required, but it is basically the only option other than making the user RDB$ADMIN, or granting them the minimum necessary rights on all individual objects.

I don't think SELECT_ANY_OBJECT_IN_DATABASE should include USAGE, as USAGE on a sequence also conveys the right to modify the sequence value, so it's not equivalent to select access.

[mrotteveel]

It might be a sign that there needs to a separate USAGE_ON_ANY_OBJECT_IN_DATABASE privilege, or that there is a gap in the privileges, and there should be a SELECT privilege on sequences which allows you to inspect the current value, e.g. GEN_ID(sequence, 0) (which I think is the only thing gbak needs here).

[aafemt]

I just wonder what for gbak needs use any user trigger...

PS: Ah, right, getting of current value is also "usage".

[mrotteveel]

I just wonder what for gbak needs use any user trigger...

PS: Ah, right, getting of current value is also "usage".

This is about sequences (generators), not triggers.

[AlexPeshkoff]

On 10/31/24 17:43, Dimitry Sibiryakov wrote: I just wonder what for gbak needs *use* any user trigger...

That's simple - to backup it's value. Any other way to get it except gen_id(x, 0) ?

[aafemt]

Oops, all DBMSs start to mix up in my head. In Oracle the current value of sequence is read from system table along with definition of the sequence.

[AlexPeshkoff]

On 10/31/24 17:39, Mark Rotteveel wrote: It might be a sign that there needs to a separate |USAGE_ON_ANY_OBJECT_IN_DATABASE| privilege, or that there is a gap in the privileges, and there should be a |SELECT| privilege on sequences which allows you to inspect the current value, e.g. |GEN_ID(sequence, 0)| (which I think is the only thing gbak needs here).

Adding USE_ANY_OBJECT_IN_DATABASE is possible way to go. Well understanding that second suggestion, an ability to inspect the current value with |SELECT| privilege, looks better I must say that mplementing it is far not trivial - privileges checked at compile time, and we can't know fr sure the value of second parameter in gen_id, it may be query or procedure parameter. If we choose this way possible solution is appropriate new info call to get generator value. As for me I prefer new privilege. | |