maria-developers team mailing list archive

[Aleksey Midenkov <midenok@xxxxxxxxx>]

Hi, Sergey!

On Sun, Jan 9, 2022 at 4:53 PM Sergei Golubchik <serg@xxxxxxxxxxx> wrote:
>
> 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@xxxxxxxxxxx



-- 
@midenok