Replication stops if GRANT issued by NON-DBA user who has RDB$ADMIN role and appropriate object (table, etc) belongs to another user

[pavel-zotov]

Replication can be unexpectedly terminated (infinitely issuing message "ERROR: unsuccessful metadata update") if the following conditions are true:

• two users exist (names: JUNIOR and MANAGER); one of them (MANAGER) has grant to CREATE TABLE and creates some table;
• one more user exists (name: SENIOR) and role RDB$ADMIN was granted to him; he is NOT the owner of database;
• user SENIOR issues GRANT to JUNIOR for run DML against the table that was created by MANAGER;see below line marked as [ 1 ];

After short time replication stops with infinitely issuing message in repl.log:

	ERROR: unsuccessful metadata update
	GRANT failed
	no INSERT privilege with grant option on table/view "PUBLIC"."TABLE_OF_MANAGER"
	At segment 3, offset 48

Script (will not raise any errror):

set bail on;
set list on;
set wng off;
set echo on;

connect 'localhost:db_repl_alias' user sysdba password 'masterkey';
create or alter user junior password '123';
create or alter user manager password '456';
create or alter user senior password '789';
commit;

connect 'localhost:db_main_alias' user sysdba password 'masterkey';
create or alter user junior password '123';
create or alter user manager password '456';
create or alter user senior password '789';
revoke all on all from junior;
revoke all on all from manager;
revoke all on all from senior;

grant rdb$admin to senior;
grant create table to user manager;

commit;
show grants;

connect 'localhost:db_main_alias' user manager password '456';
recreate table table_of_manager(id int primary key, info varchar(50) default current_user);
insert into table_of_manager(id) values(1);
commit;

connect 'localhost:db_main_alias' user senior password '789' role rdb$admin;

grant insert on table_of_manager to junior;     --  [ 1 ] ::: NB :::: THIS IS DONE BY **SENIOR**, NOT SYSDBA!
commit;

show grants;
commit;

-- Just to check actual grants that user 'junior' has:
connect 'localhost:db_main_alias' user junior password '123';

show grants;

-- must pass:
insert into table_of_manager(id) values(-1);
commit;

connect 'localhost:db_main_alias' user manager password '456';

-- two rows must be shown:
select * from table_of_manager;

Example of replication log after this:

PZ (replica) Tue Jan 13 14:18:27 2026
	Database: C:\FB\60SS\EXAMPLES\EMPBUILD\QA_REPLICATION\DB_REPL.FDB
	VERBOSE: Added 4 segment(s) to the queue

PZ (replica) Tue Jan 13 14:18:27 2026
	Database: C:\FB\60SS\EXAMPLES\EMPBUILD\QA_REPLICATION\DB_REPL.FDB
	VERBOSE: Segment 1 (595 bytes) is replicated in 0.060s, deleting

PZ (replica) Tue Jan 13 14:18:27 2026
	Database: C:\FB\60SS\EXAMPLES\EMPBUILD\QA_REPLICATION\DB_REPL.FDB
	VERBOSE: Segment 2 (356 bytes) is replicated in 0.020s, deleting

PZ (replica) Tue Jan 13 14:18:27 2026
	Database: C:\FB\60SS\EXAMPLES\EMPBUILD\QA_REPLICATION\DB_REPL.FDB
	ERROR: unsuccessful metadata update
	GRANT failed
	no INSERT privilege with grant option on table/view "PUBLIC"."TABLE_OF_MANAGER"
	At segment 3, offset 48

PZ (replica) Tue Jan 13 14:18:27 2026
	Database: C:\FB\60SS\EXAMPLES\EMPBUILD\QA_REPLICATION\DB_REPL.FDB
	VERBOSE: Disconnecting and suspending

PZ (replica) Tue Jan 13 14:18:30 2026
	Database: C:\FB\60SS\EXAMPLES\EMPBUILD\QA_REPLICATION\DB_REPL_8766.FDB
	VERBOSE: No new segments found, suspending

PZ (replica) Tue Jan 13 14:18:33 2026
	Database: C:\FB\60SS\EXAMPLES\EMPBUILD\QA_REPLICATION\DB_REPL_8766.FDB
	VERBOSE: No new segments found, suspending

PZ (replica) Tue Jan 13 14:18:34 2026
	Database: C:\FB\60SS\EXAMPLES\EMPBUILD\QA_REPLICATION\DB_REPL.FDB
	VERBOSE: Added 2 segment(s) to the queue

PZ (replica) Tue Jan 13 14:18:34 2026
	Database: C:\FB\60SS\EXAMPLES\EMPBUILD\QA_REPLICATION\DB_REPL.FDB
	ERROR: unsuccessful metadata update
	GRANT failed
	no INSERT privilege with grant option on table/view "PUBLIC"."TABLE_OF_MANAGER"
	At segment 3, offset 48

PZ (replica) Tue Jan 13 14:18:34 2026
	Database: C:\FB\60SS\EXAMPLES\EMPBUILD\QA_REPLICATION\DB_REPL.FDB
	VERBOSE: Disconnecting and suspending

replication.conf:

database
{
  verbose_logging = true
}

database = $(dir_sampleDb)/qa_replication/db_main.fdb
{

    journal_directory = "$(dir_sampleDb)/qa_replication/db_main.journal"
    journal_archive_directory = "$(dir_sampleDb)/qa_replication/db_main.archive"
    journal_archive_timeout = 10
}

database = $(dir_sampleDb)/qa_replication/db_repl.fdb
{
    journal_source_directory = "$(dir_sampleDb)/qa_replication/db_main.archive"
    apply_idle_timeout = 3
    apply_error_timeout = 7
}

Reproduced on:
6.0.0.1389; 5.0.4.1746; 4.0.73243.

[hvlad]

The root of the issue is that replicator applies DDL statement not taking active role into account.

In this case:
on main database: grant insert on table_of_manager to junior was executed by user SENIOR with active role RDB$ADMIN, while
on replica database: same statement is executed by user SENIOR and no active role - thus it fails with error.

As workaround one may set RDB$ADMIN as default role for user SENIOR: grant default rdb$admin to senior

Of course, the bug in replication should be fixed and active role should be used on replica side.
At first look, it requires changes in replication protocol.

[dyemanov]

Ideally, all permission checks should be skipped on the replica side, because if the statement succeeded on the primary, then it should be applied to the replica. This is currently true for DML and mostly DDL too, however GRANT/REVOKE has some special checks that may break replication.

If the active role RDB$ADMIN does not affect data written to system tables, then it should be fixable without protocol changes.

[hvlad]

If the active role RDB$ADMIN does not affect data written to system tables, then it should be fixable without protocol changes.

Not sure I got you here: GRANT definitely writes into system tables

[dyemanov]

Not sure I got you here: GRANT definitely writes into system tables

I meant, does the active RDB$ADMIN role somehow affect what it writes into the system tables? Or it affects only the exception being raised?

[hvlad]

AFAIU, active role doesn't (and shouldn't) affect what data go into system tables when GRANT stmt is executed.
So, it is interesting how do you offer to fix such case without protocol changes.

[dyemanov]

I was thinking about something like this:

diff --git a/src/jrd/Attachment.h b/src/jrd/Attachment.h
index 44d242d1c0..968ae63ade 100644
--- a/src/jrd/Attachment.h
+++ b/src/jrd/Attachment.h
@@ -872,6 +872,9 @@ private:
 
 inline bool Attachment::locksmith(thread_db* tdbb, SystemPrivilege sp) const
 {
+       if (tdbb->tdbb_flags & TDBB_replicator)
+               return true;
+
        const auto user = getEffectiveUserId();
        return (user && user->locksmith(tdbb, sp));
 }

[hvlad]

If you consider this safe and correct - I don't object. This is definitely easiest way to fix the issue ;)