1. 16 Jun, 2011 1 commit
  2. 10 Jun, 2011 2 commits
  3. 10 May, 2011 1 commit
  4. 06 May, 2011 1 commit
  5. 05 May, 2011 1 commit
  6. 04 May, 2011 3 commits
  7. 28 Apr, 2011 1 commit
    • Georgi Kodinov's avatar
      Bug #11764517: 57359: POSSIBLE TO CIRCUMVENT SECURE_FILE_PRIV · 4c5dfc00
      Georgi Kodinov authored
        USING '..' ON WINDOWS
      
      Backport of the fix to 5.0 (to be null-merged to 5.1).
      Moved the test into the main test suite. 
      Made mysql-test-run.pl to not use symlinks for sdtdata as the symlinks
      are now properly recognized by secure_file_priv.
      Made sure the paths in load_file(), LOAD DATA and SELECT .. INTO OUTFILE 
      that are checked against secure_file_priv in a correct way similarly to 5.1 
      by the extended is_secure_file_path() backport before the comparison.
      Added an extensive test with all the variants of upper/lower case, 
      slash/backslash and case sensitivity.
      Added few comments to the code.
      4c5dfc00
  8. 18 Apr, 2011 1 commit
  9. 13 Apr, 2011 1 commit
  10. 11 Apr, 2011 6 commits
  11. 07 Apr, 2011 1 commit
  12. 22 Mar, 2011 2 commits
    • Magne Mahre's avatar
      Post-push fix for Bug 11896296 · 40af5949
      Magne Mahre authored
      Didn't build on Solaris.
      40af5949
    • Magne Mahre's avatar
      Bug#11896296 REMOVE LGPL LICENSED FILES IN MYSQL 5.0 · 7606856e
      Magne Mahre authored
      The LGPL license is used in some legacy code, and to
      adhere to current licensing polity, we remove those
      files that are no longer used, and reorganize the
      remaining LGPL code so it will be GPL licensed from
      now on.
      
      Note:  This patch only removed LGPL licensed files
             in MySQL 5.0, and is the first of a set of
             patches to remove LGPL from all trees.
             (See Bug# 11840513 for details)
      7606856e
  13. 21 Mar, 2011 3 commits
  14. 16 Mar, 2011 1 commit
  15. 09 Mar, 2011 2 commits
  16. 16 Feb, 2011 1 commit
  17. 10 Feb, 2011 1 commit
  18. 09 Feb, 2011 2 commits
  19. 08 Feb, 2011 2 commits
  20. 07 Feb, 2011 1 commit
    • Dmitry Lenev's avatar
      Fix for bug#36544 "DROP USER does not remove stored function · e960abc7
      Dmitry Lenev authored
      privileges".
      
      The first problem was that DROP USER didn't properly remove privileges 
      on stored functions from in-memory structures. So the dropped user
      could have called stored functions on which he had privileges before
      being dropped while his connection was still around.
      Even worse if a new user with the same name was created he would
      inherit privileges on stored functions from the dropped user.
      Similar thing happened with old user name and function privileges
      during RENAME USER.
      
      This problem stemmed from the fact that the handle_grant_data() function
      which handled DROP/RENAME USER didn't take any measures to update
      in-memory hash with information about function privileges after
      updating them on disk.
      
      This patch solves this problem by adding code doing just that.
      
      The second problem was that RENAME USER didn't properly update in-memory
      structures describing table-level privileges and privileges on stored 
      procedures. As result such privileges could have been lost after a rename
      (i.e. not associated with the new name of user) and inherited by a new
      user with the same name as the old name of the original user.
      
      This problem was caused by code handling RENAME USER in
      handle_grant_struct() which [sic!]:
      a) tried to update wrong (tables) hash when updating stored procedure
         privileges for new user name.
      b) passed wrong arguments to function performing the hash update and
         didn't take into account the way in which such update could have
         changed the order of the hash elements.
      
      This patch solves this problem by ensuring that a) the correct hash
      is updated, b) correct arguments are used for the hash_update()
      function and c) we take into account possible changes in the order
      of hash elements.
      e960abc7
  21. 02 Feb, 2011 2 commits
    • Georgi Kodinov's avatar
      6954b672
    • Georgi Kodinov's avatar
      Fixes for Bug #55755 and Bug #52315 part 2 · 59f68983
      Georgi Kodinov authored
      Bug #55755 : Date STD variable signness breaks server on FreeBSD and OpenBSD
      
      * Added a check to configure on the size of time_t
      * Created a macro to check for a valid time_t that is safe to use with datetime 
        functions and store in TIMESTAMP columns.
      * Used the macro consistently instead of the ad-hoc checks introduced by 52315
      * Fixed compliation warnings on platforms where the size of time_t is smaller than
        the size of a long (e.g. OpenBSD 4.8 64 amd64).
      
      Bug #52315: utc_date() crashes when system time > year 2037
      
      * Added a correct check for the timestamp range instead of just variable size check to
      SET TIMESTAMP.
      * Added overflow checking before converting to time_t. 
      * Using a correct localized error message in this case instead of the generic error.
      * Added a test suite.
      * fixed the checks so that they check for unsigned time_t as well. Used the checks 
        consistently across the source code.
      * fixed the original test case to expect the new error code.
      59f68983
  22. 28 Jan, 2011 1 commit
  23. 26 Jan, 2011 2 commits
  24. 15 Jan, 2011 1 commit
    • 's avatar
      BUG#49124 Security issue with /*!-versioned */ SQL statements on Slave · ade1c74b
      authored
      Backport to 5.0.
      
      /*![:version:] Query Code */, where [:version:] is a sequence of 5 
      digits representing the mysql server version(e.g /*!50200 ... */),
      is a special comment that the query in it can be executed on those 
      servers whose versions are larger than the version appearing in the 
      comment. It leads to a security issue when slave's version is larger 
      than master's. A malicious user can improve his privileges on slaves. 
      Because slave SQL thread is running with SUPER privileges, so it can
      execute queries that he/she does not have privileges on master.
            
      This bug is fixed with the logic below: 
      - To replace '!' with ' ' in the magic comments which are not applied on
        master. So they become common comments and will not be applied on slave.
            
      - Example:
        'INSERT INTO t1 VALUES (1) /*!10000, (2)*/ /*!99999 ,(3)*/
         will be binlogged as
        'INSERT INTO t1 VALUES (1) /*!10000, (2)*/ /* 99999 ,(3)*/
      ade1c74b