1. 21 Jan, 2010 1 commit
    • Georgi Kodinov's avatar
      Bug #50276: Security flaw in INFORMATION_SCHEMA.TABLES · 2c44919b
      Georgi Kodinov authored
      check_access() returning false for a database does not
      guarantee that the access is granted to it.
      This wrong condition in filling the INFORMATION_SCHEMA
      tables causes extra tables to be returned to the user
      even if he has no rights to see them.
      Fixed by correcting the condition.
      2c44919b
  2. 02 Feb, 2010 5 commits
    • Georgi Kodinov's avatar
      Bug #49445: Assertion failed: 0, file .\item_row.cc, line 55 with · 4cfda7fd
      Georgi Kodinov authored
        fulltext search and row op.
      
      The search for fulltext indexes is searching for some special 
      predicate layouts. While doing so it's not checking for the number
      of columns of the expressions it tries to calculate.
      And since row expressions can't return a single scalar value there
      was a crash.
      Fixed by checking if the expressions are scalar (in addition to 
      being constant) before calling Item::val_xxx() methods.
      4cfda7fd
    • Magne Mahre's avatar
      Cleanup fix for WL#5154 that splits commands handling for · 632cf4c5
      Magne Mahre authored
      --default-character-set and --character-set-server such
      that only the first will give a deprecation warning.
      Apart from that, the two options should do the same.
      632cf4c5
    • Alexander Nozdrin's avatar
      Revert a patch for Bug#48231, which introduced valgrind warnings. · f392edda
      Alexander Nozdrin authored
      Original revision:
      ------------------------------------------------------------
      revision-id: li-bing.song@sun.com-20100130124925-o6sfex42b6noyc6x
      parent: joro@sun.com-20100129145427-0n79l9hnk0q43ajk
      committer: <Li-Bing.Song@sun.com>
      branch nick: mysql-5.1-bugteam
      timestamp: Sat 2010-01-30 20:49:25 +0800
      message:
        Bug #48321  CURRENT_USER() incorrectly replicated for DROP/RENAME USER;
                    REVOKE/GRANT; ALTER EVENT.
        
        The following statements support the CURRENT_USER() where a user is needed.
          DROP USER 
          RENAME USER CURRENT_USER() ...
          GRANT ... TO CURRENT_USER()
          REVOKE ... FROM CURRENT_USER()
          ALTER DEFINER = CURRENT_USER() EVENT
        but, When these statements are binlogged, CURRENT_USER() just is binlogged
        as 'CURRENT_USER()', it is not expanded to the real user name. When slave 
        executes the log event, 'CURRENT_USER()' is expand to the user of slave 
        SQL thread, but SQL thread's user name always NULL. This breaks the replication.
        
        After this patch, All above statements are rewritten when they are binlogged.
        The CURRENT_USER() is expanded to the real user's name and host.
      ------------------------------------------------------------
      f392edda
    • Davi Arnaut's avatar
    • Georgi Kodinov's avatar
      be89d30f
  3. 01 Feb, 2010 3 commits
  4. 30 Jan, 2010 1 commit
    • 's avatar
      Bug #48321 CURRENT_USER() incorrectly replicated for DROP/RENAME USER; · 788c28ac
      authored
                  REVOKE/GRANT; ALTER EVENT.
      
      The following statements support the CURRENT_USER() where a user is needed.
        DROP USER 
        RENAME USER CURRENT_USER() ...
        GRANT ... TO CURRENT_USER()
        REVOKE ... FROM CURRENT_USER()
        ALTER DEFINER = CURRENT_USER() EVENT
      but, When these statements are binlogged, CURRENT_USER() just is binlogged
      as 'CURRENT_USER()', it is not expanded to the real user name. When slave 
      executes the log event, 'CURRENT_USER()' is expand to the user of slave 
      SQL thread, but SQL thread's user name always NULL. This breaks the replication.
      
      After this patch, All above statements are rewritten when they are binlogged.
      The CURRENT_USER() is expanded to the real user's name and host.
      788c28ac
  5. 29 Jan, 2010 3 commits
  6. 28 Jan, 2010 1 commit
  7. 29 Jan, 2010 2 commits
  8. 28 Jan, 2010 3 commits
  9. 27 Jan, 2010 9 commits
  10. 26 Jan, 2010 3 commits
  11. 25 Jan, 2010 2 commits
    • Andrei Elkin's avatar
      Bug #47142 "slave start until" stops 1 event too late in 4.1 to 5.0 replication · 1c0056b3
      Andrei Elkin authored
      When replicating from 4.1 master to 5.0 slave START SLAVE UNTIL can stop too late.
      The necessary in calculating of the beginning of an event the event's length
      did not correspond to the master's genuine information at the event's execution time.
      That piece of info was changed at the event's relay-logging due to binlog_version<4 event
      conversion by IO thread.
      
      Fixed with storing the master genuine Query_log_event size into a new status
      variable at relay-logging of the event. The stored info is extacted at the event
      execution and participate further to caclulate the correct start position of the event
      in the until-pos stopping routine.
      The new status variable's algorithm will be only active when the event comes
      from the master of version < 5.0 (binlog_version < 4).
      1c0056b3
    • 's avatar
      Manual merge with Conflicts: · 8a66b424
      authored
      sql_udf.cc
      8a66b424
  12. 24 Jan, 2010 1 commit
  13. 22 Jan, 2010 6 commits