Hi, Sergey!
On Sun, Jan 9, 2022 at 4:53 PM Sergei Golubchik
Hi, Aleksey!
On Jan 09, Aleksey Midenkov wrote:
revision-id: 88f8aa20bba (mariadb-10.3.31-79-g88f8aa20bba) parent(s): d5451867af1 author: Aleksey Midenkov committer: Aleksey Midenkov timestamp: 2021-12-23 04:15:39 +0300 message:
MDEV-23486 RBR can bypass secure_timestamp=YES
Pass to a slave whether master table is system-versioned via TM_SYSTEM_VERSIONED flag. That deprecates m_vers_from_plain detection. If secure_timestamp == YES or master did not supply row_end data treat the row as current data and generate timestamps for it.
I don't understand why does it matter whether the master is system versioned or not.
secure_timestamp=YES means the table has to store actual timestamps when rows were changed. It doesn't trust the master to set timestamps. So it should not matter whether master table is versioned or not, if you don't trust the master, you cannot trust its TM_SYSTEM_VERSIONED flag either. Even if the table was system versioned on the master, the master could've had secure_timestamp=NO and a completely fake history.
If slave ignores completely row_start/row_end coming from the master how it can tell if row is history or not? UPDATE sends 2 events: Update_rows and Write_rows. How can we tell what row_end value to assign when processing Write_rows: as for history or as for current data? If the master can fake history it can fake any data. So if we even somehow protected the history, like generate always on slave, if master sends fake current data then it becomes fake history. I don't see a good reason for such a kind of protection. The better protection would be to organize secure communication: encrypt binlog, sign events with certificates, etc.
Regards, Sergei VP of MariaDB Server Engineering and security@mariadb.org
-- @midenok