Re: [Maria-developers] 88f8aa20bba: MDEV-23486 RBR can bypass secure_timestamp=YES

2022-03-26 Thread Aleksey Midenkov
Hi, Sergey!

On Sun, Jan 9, 2022 at 4:53 PM Sergei Golubchik  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 secur...@mariadb.org



-- 
@midenok

___
Mailing list: https://launchpad.net/~maria-developers
Post to : maria-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Maria-developers] 88f8aa20bba: MDEV-23486 RBR can bypass secure_timestamp=YES

2022-01-09 Thread 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.

Regards,
Sergei
VP of MariaDB Server Engineering
and secur...@mariadb.org

___
Mailing list: https://launchpad.net/~maria-developers
Post to : maria-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-developers
More help   : https://help.launchpad.net/ListHelp