Details

    • Task
    • Status: Open (View Workflow)
    • Major
    • Resolution: Unresolved
    • N/A
    • Replication
    • None

    Description

      This toplevel ticket captures work related to binlog corruption. Broadly speaking, there appear to be four paths forward, three on the server and one in the client. On the server, we could (1) implement sandboxing for plugins (Andrei's comment "prevent faulty plugins"), (2) prevent binlog corruption from occurring, (3) warn when binlog corruption occurs (e.g. by detecting possible binlog corruption with timestamp checks as described in the ticket). On the client, we can find traces of corruption (some minimum length string of null bytes) enabled a new commandline option.

      Attachments

        Issue Links

          Activity

            Another idea would be to incorporate the last modified timestamp of the binary logs to find if someone unexpected has tampered with the binary log file. That is, within mariadbd, we would cache the time that we last wrote to the binary log file. Then, before writing an ever, we would compare our last cached timestamp against that which the file-system reports. If the file system reports a last modified date that is after the timestamp when we last wrote an event, we'd know it has been tampered with (and possibly corrupted). Then, we could write a warning to the error log with the file system's reported last modified date, which could be used to cross-reference other logs on the server to see what was happening at that time (e.g. system logs, other mariadbd logs, etc).

            bnestere Brandon Nesterenko added a comment - Another idea would be to incorporate the last modified timestamp of the binary logs to find if someone unexpected has tampered with the binary log file. That is, within mariadbd, we would cache the time that we last wrote to the binary log file. Then, before writing an ever, we would compare our last cached timestamp against that which the file-system reports. If the file system reports a last modified date that is after the timestamp when we last wrote an event, we'd know it has been tampered with (and possibly corrupted). Then, we could write a warning to the error log with the file system's reported last modified date, which could be used to cross-reference other logs on the server to see what was happening at that time (e.g. system logs, other mariadbd logs, etc).
            Elkin Andrei Elkin added a comment -

            To explore the fs timestamp more, remembering by MYSQL_BIN_LOG object the last modification timestamp could be done always. Later then an error read from the current binlog occurs, MYSQL_BIN_LOG::last_modified_ts would be compared against the FileSystem's version. A mismatch would obviously indicate the fact of a illegal writer at the FS::last_modified_ts.

            Elkin Andrei Elkin added a comment - To explore the fs timestamp more, remembering by MYSQL_BIN_LOG object the last modification timestamp could be done always. Later then an error read from the current binlog occurs, MYSQL_BIN_LOG::last_modified_ts would be compared against the FileSystem's version. A mismatch would obviously indicate the fact of a illegal writer at the FS::last_modified_ts.
            Gosselin Dave Gosselin added a comment - https://mariadb.slack.com/archives/C60QTMTEJ/p1722003199523709?thread_ts=1712069916.067259&cid=C60QTMTEJ
            Gosselin Dave Gosselin added a comment -

            Hi Brandon, reassigning to you. I had posted a PR for this but we decided to hold off on merging it, it was https://github.com/MariaDB/server/pull/3473

            Gosselin Dave Gosselin added a comment - Hi Brandon, reassigning to you. I had posted a PR for this but we decided to hold off on merging it, it was https://github.com/MariaDB/server/pull/3473

            People

              bnestere Brandon Nesterenko
              Elkin Andrei Elkin
              Votes:
              1 Vote for this issue
              Watchers:
              8 Start watching this issue

              Dates

                Created:
                Updated:

                Git Integration

                  Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.