-
-
Notifications
You must be signed in to change notification settings - Fork 205
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DDL-Changes in replication does not set the correct grantor #8058
Comments
This could be fixed in two ways:
Can anyone think of any other solution? |
Cannot Applier just set both att_user and att_ss_user in executeSql()? |
This is what I meant by (1) above. But I'm not sure whether it will be enough. What if some privileges weren't loaded and cached yet (for the original att_user) and it will be initiated during replication (for the temporary att_user)? |
Alternatively Applier can be allowed to perform DML on system tables and DDL being replicated as DML. And bypass security completely by setting of FLAG_POWERFUL. |
AFAIU, it will bind layout of replica's system tables to the master's one, and thus disable replication of DDL statements between different Firebird versions. |
The same problem as with new/modified DDL statements. But at DML level it can be solved more easily by some kind of "smart" processing of system tables on source and target side while modification of plain SQL text to comply current version is more tricky. PS: May be we should just solve actual error and allow grantee to revoke privileges from itself regardless of who they were granted by?.. |
The initial implementation was pure DML and it was proven to be fragile in practice, hence I switched to statement level replication for DDL. |
Currently access checks are disabled for the applier, so maybe it's really safe to just substitute |
Hi,
I am using the async-Replication and in with DDL-Changes (chreate table), the grantor is not set correct. This ensures that replication stops
Here is my way to reproduce it in FB 4.0.4 and 5.0.
I'm using a Windows 11-machine, but also had this seen on a Linux-machine.
isql employee -user SYSDBA
create user DBOwner password '1234' Grant Admin role;
In Primary: RDB$User = DBOWNER and RDB$GRANTOR = DBOWNER
In Secondary: RDB$User = DBOWNER and RDB$GRANTOR = SYSDBA
My expectation is that the Grantor on the secondary side is the same as on the primary side. Or that you can specify in the config file who executes the replication statments on the secondary side.
I didn't find something in the Documentation to this.
Regards, Jan
The text was updated successfully, but these errors were encountered: