svn commit - mysqldoc@docsrva: r22956 - trunk/dynamic-docs/changelog

[jon.stephens]

Author: jstephens
Date: 2010-10-02 10:01:40 +0200 (Sat, 02 Oct 2010)
New Revision: 22956

Log:

Publish changelog entry for Replication BUG#49124



Modified:
   trunk/dynamic-docs/changelog/mysqld-2.xml


Modified: trunk/dynamic-docs/changelog/mysqld-2.xml
===================================================================
--- trunk/dynamic-docs/changelog/mysqld-2.xml	2010-10-01 18:25:30 UTC (rev 22955)
+++ trunk/dynamic-docs/changelog/mysqld-2.xml	2010-10-02 08:01:40 UTC (rev 22956)
Changed blocks: 1, Lines Added: 125, Lines Deleted: 0; 5248 bytes

@@ -6,6 +6,131 @@
 ]>
 <changelog>
 
+  <logentry entrytype="bug">
+
+    <tags>
+      <highlight type="securityfix"/>
+      <highlight type="replication"/>
+      <manual type="comments"/>
+    </tags>
+
+    <bugs>
+      <fixes bugid="49124"/>
+    </bugs>
+
+    <versions>
+      <version ver="5.1.50"/>
+      <version ver="5.5.6"/>
+      <version ver="5.6.0"/>
+    </versions>
+
+    <message>
+
+      <para>
+        It was possible when using statement-based replication to
+        subvert the MySQL privilege system on a slave with a higher
+        server release version number than that of the master by using
+        version-specific comments in statements run on the master.
+      </para>
+
+      <para>
+        A more detailed explanation follows:
+      </para>
+
+      <para>
+        In MySQL, a version-specific comment is an SQL comment of the
+        form <literal>/*!<replaceable>nnnnn</replaceable>
+        <replaceable>sql</replaceable> */</literal> where
+        <replaceable>nnnnn</replaceable> represents a MySQL release
+        version number and <replaceable>sql</replaceable> represents a
+        string of SQL, or a portion of a string of SQL, that should be
+        executed by the MySQL Server only if the server version is at
+        least version <replaceable>n.nn</replaceable>. (For additional
+        information and an example, see <xref linkend="comments"/>.)
+      </para>
+
+      <para>
+        In MySQL replication, the slave SQL thread executes with the
+        <literal role="priv">SUPER</literal> privilege, regardless of
+        the privileges with which statements are originally executed on
+        the master. Specific to this issue, when using statement-based
+        replication it was possible, when the slave was of a higher
+        MySQL version than the master, to run statements that would have
+        failed on the master due to insufficient privileges, except that
+        these statements were wrapped in version-specific comments where
+        the encoded version was greater than the MySQL server version of
+        the master. However, if the MySQL release version of the slave
+        was equal to or greater than the version encoded in the comment,
+        the same statements could execute on this slave whose MySQL
+        release version was less than the version number used in the
+        comment.
+      </para>
+
+      <para>
+        Suppose that a master running MySQL 5.1.48 replicated to a slave
+        running MySQL 4.1.49, and that a user <literal>user1</literal>
+        had privileges to run <literal role="stmt">UPDATE</literal>
+        statements on database <literal>db1</literal> but no privileges
+        at all on the <literal>mysql</literal> system database, so that
+        the first of the following two statements succeeded, but the
+        second statement failed, and thus the first statement was
+        written to the binary log, but the second statement was not:
+      </para>
+
+<programlisting>      
+UPDATE db1.tb1 SET db1.tbl1.col1=2;
+ 
+UPDATE mysql.user SET mysql.user.Super_priv='Y' 
+    WHERE mysql.user.User='user1';
+</programlisting>
+
+      <para>
+        However, the text of the second statement could be wrapped in
+        version-specific comments and thus <quote>hidden</quote> within
+        the text of the first statement so that this new version of the
+        first statement succeeded, and was written in its entireity to
+        the binary log. The new statement containing the necessary
+        portions of the statement affecting the
+        <quote>mysql.user</quote> table wrapped within version-specific
+        comments is shown here:
+      </para>
+
+<programlisting>
+UPDATE db1.tbl1 /*!514900 ,mysql.user */ 
+    SET db1.tbl1.col1=2 /*!514900 ,mysql.user.Super_priv='Y'
+    WHERE mysql.user.User='user1'*/;
+</programlisting>
+
+      <para>
+        Thus, a 5.1.48 master would see this statement as identical to
+        the first of the original two statements shown previously
+        (<literal>UPDATE db1.tb1 SET db1.tbl1.col1=2</literal>).
+        However, the version-specific comments within the statement just
+        shown, when run on the MySQL 5.1.49 slave, were ignored; thus
+        the slave SQL thread would execute the statement, as shown here,
+        with the <literal role="priv">SUPER</literal> privilege, on the
+        slave:
+      </para>
+
+<programlisting>      
+UPDATE db1.tbl1,mysql.user 
+    SET db1.tbl1.col1=2,mysql.user.Super_priv='Y'
+    WHERE mysql.user.User='user1';
+</programlisting>
+
+      <para>
+        To fix this issue, the <literal>!</literal> (exclamation)
+        character is now stripped from comments prior to statements
+        containing them being applied on replication slaves; thus,
+        version-specific comments that are not applied on the master are
+        treated as normal comments on the slave and also not applied
+        there.
+      </para>
+
+    </message>
+
+  </logentry>
+
   <logentry entrytype="feature">
 
     <tags>