> Why it shouldn't be a privilege?

Because that's necessity :)) (sorry, could not resist).

> What's wrong with creating a backup operators group/role instead of
> giving these persons my dbowner password?

Nothing wrong, really correct approach, but wrong conclusion that this
also needs new priviledge.

> I'm not 100% sure in that either ;-) But we need a number of
> concurrent suggestions to understand our needs better.

See below.

> Honestly, I don't like the Borland's way. And they don't support
> INSERT/DELETE against monitoring tables, only UPDATE of the
> RDB$STATE column is allowed. This is not obvious behaviour at all.
> And this doesn't address the backup/restore facility in any way.

INSERT INTO SYS$BACKUPS(SYS$DESTINATION)
VALUES('/var/db/backups/my.fbk');

Entry is automatically removed as soon as backup is completed. But
that is an ill approach.

What in fact we have are 4 DML operations and a number of database
objects on which one can execute those operations. So we have 4xN
possible combinations (N - number of database objects). GRANT is quite
natural here.

Backup, statistics gathering, etc. work only with one object -
database. One can say that then we need priviledges for all operations
that can be executed on this object, but we define 2xM entites, where
in fact we could happily live with only 1xM. Also I am afraid that
this will make system monolythic.

What in fact we need, is a priviledge to perform that operation. And
we already have this priviledge - GRANT EXECUTE PROCEDURE ON ...

So what is left, is to export all those database level operations as
procedures and then simply grant EXECUTE PROCEDURE on the
corresponding object to corresponding roles with GRANT OPTION.

Also I think that it would be wise to consider this as part of
External SP concept. In few words, there is a module (for example,
backup.dll) that is loaded by the engine at startup and is
initialized. Module checks the procedures defined for the database, if
necessary defines its own procedures with entry points pointing to its
own exports. Something like:

CREATE ROLE BACKUP;

CREATE PROCEDURE BACKUP_DATABASE(
PATH VARCHAR(255)
) RETURNS (
STATUS INTEGER
)
MODULE NAME 'backup.dll'
ENTRY POINT 'isc_backup_database';

GRANT EXECUTE PROCEDURE BACKUP_DATABASE TO BACKUP WITH GRANT OPTION;

Now backup supervisor (I do not use word "manager" not to confuse
person with backup.dll) can do

GRANT EXECUTE PROCEDURE BACKUP_DATABASE TO SAM;

and Sam can do

EXECUTE PROCEDURE BACKUP_DATABASE('/home/sam/backup/my.fbk');

We (Firebird project) can provide simple backup managers with almost
no parameters, but people can create their own backup managers that
can, for example, encrypt the database, run backups in timely fashion
(remember, backup.dll is a plugin, it runs as long as server runs) and
so on.

Roman