1. 21 Mar, 2011 1 commit
  2. 16 Mar, 2011 1 commit
  3. 09 Mar, 2011 1 commit
  4. 16 Feb, 2011 1 commit
  5. 10 Feb, 2011 1 commit
  6. 09 Feb, 2011 2 commits
  7. 08 Feb, 2011 1 commit
  8. 07 Feb, 2011 1 commit
    • Dmitry Lenev's avatar
      Fix for bug#36544 "DROP USER does not remove stored function · b169b8d8
      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.
      
      mysql-test/r/grant.result:
        Added test coverage for bug#36544 "DROP USER does not remove stored
        function privileges".
      mysql-test/suite/funcs_1/r/innodb_storedproc_06.result:
        Since after fixing bug#36544 "DROP USER does not remove stored function
        privileges" in-memory structures are correctly updated by DROP USER,
        DROP FUNCTION performed after DROP USER for its definer no longer
        produces unwarranted warning/error messages.
      mysql-test/suite/funcs_1/r/memory_storedproc_06.result:
        Since after fixing bug#36544 "DROP USER does not remove stored function
        privileges" in-memory structures are correctly updated by DROP USER,
        DROP FUNCTION performed after DROP USER for its definer no longer
        produces unwarranted warning/error messages.
      mysql-test/suite/funcs_1/r/myisam_storedproc_06.result:
        Since after fixing bug#36544 "DROP USER does not remove stored function
        privileges" in-memory structures are correctly updated by DROP USER,
        DROP FUNCTION performed after DROP USER for its definer no longer
        produces unwarranted warning/error messages.
      mysql-test/t/grant.test:
        Added test coverage for bug#36544 "DROP USER does not remove stored
        function privileges".
      sql/sql_acl.cc:
        Changed handle_grant_data() to also update hash with function 
        privileges. This allows DROP/RENAME USER correctly keep this 
        in-memory structure up-to-date.
        
        To do this extended handle_grant_struct() to support updating of this
        hash. In addition fixed code in this function which is responsible for 
        handling of column and routine hashes during RENAME USER, ensured that
        we correctly update these hashes after changing user name and that we
        don't skip elements while iterating through the hash and doing updates.
      b169b8d8
  9. 02 Feb, 2011 2 commits
    • Georgi Kodinov's avatar
      0a8419df
    • Georgi Kodinov's avatar
      Fixes for Bug #55755 and Bug #52315 part 2 · a70c34bf
      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.
      a70c34bf
  10. 28 Jan, 2011 1 commit
  11. 26 Jan, 2011 2 commits
    • Ramil Kalimullin's avatar
      Bug #47811 : remove the non-default alignment specification. · 7083cb0b
      Ramil Kalimullin authored
      Fix backported from to 5.0.
      "Remove the alignment option, let valgrind use its default"
      
      
      mysql-test/mysql-test-run-shell.sh:
        Bug #47811 : remove the non-default alignment specification.
          - backport from 5.1
           "Remove the alignment option, let valgrind use its default"
      mysql-test/mysql-test-run.pl:
        Bug #47811 : remove the non-default alignment specification.
          - backport from 5.1
           "Remove the alignment option, let valgrind use its default"
      7083cb0b
    • Libing Song's avatar
      Postfix bug#49124 · 8ec9bbaf
      Libing Song authored
      Updated the copyright.
      8ec9bbaf
  12. 15 Jan, 2011 1 commit
    • unknown's avatar
      BUG#49124 Security issue with /*!-versioned */ SQL statements on Slave · 12c6d1f3
      unknown 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)*/
      12c6d1f3
  13. 13 Jan, 2011 2 commits
  14. 07 Jan, 2011 1 commit
  15. 29 Dec, 2010 1 commit
  16. 28 Dec, 2010 1 commit
    • Kent Boortz's avatar
      - Added/updated copyright headers · 85323eda
      Kent Boortz authored
      - Removed files specific to compiling on OS/2
      - Removed files specific to SCO Unix packaging
      - Removed "libmysqld/copyright", text is included in documentation
      - Removed LaTeX headers for NDB Doxygen documentation
      - Removed obsolete NDB files
      - Removed "mkisofs" binaries
      - Removed the "cvs2cl.pl" script
      - Changed a few GPL texts to use "program" instead of "library"
      85323eda
  17. 17 Dec, 2010 2 commits
  18. 16 Dec, 2010 2 commits
    • Martin Hansson's avatar
      Merge. · d74e8c5d
      Martin Hansson authored
      d74e8c5d
    • Martin Hansson's avatar
      Bug#54568: create view cause Assertion failed: 0, · ffdeb062
      Martin Hansson authored
      file .\item_subselect.cc, line 836
           
      IN quantified predicates are never executed directly. They are rather wrapped
      inside nodes called IN Optimizers (Item_in_optimizer) which take care of the
      execution. However, this is not done during query preparation. Unfortunately
      the LIKE predicate pre-evaluates constant right-hand side arguments even
      during name resolution. Likely this is meant as an optimization.
            
      Fixed by not pre-evaluating LIKE arguments in view prepare mode.
      
      Back-ported to 5.0s
      ffdeb062
  19. 15 Dec, 2010 1 commit
    • Alexander Nozdrin's avatar
      Patch for Bug#57952 (privilege change is not taken into account by EXECUTE). · 1bd81f6b
      Alexander Nozdrin authored
      The user-visible problem was that changes to column-level privileges,
      happened in between of PREPARE and EXECUTE of a prepared statement, were
      neglected. I.e. a prepared statement could be executed with the
      column-level privileges as of PREPARE-time. The problem existed for
      column-level privileges only.
      
      A similar problem existed for stored programs: the changes between
      executions didn't have an effect.
      
      Technically the thing is that table references are cached in
      Prepared_statement::prepare() call. In subsequent
      Prepared_statement::execute() calls those cached values are used.
      There are two functions to get a field by name: find_field_in_table() and
      find_field_in_table_ref(). On prepare-phase find_field_in_table_ref() is
      called, on execute-phase -- find_field_in_table() because the table is
      cached. find_field_in_table() does not check column-level privileges and
      expects the caller to do that. The problem was that this check was
      forgotten.
      
      The fix is to check them there as it happens in find_field_in_table_ref().
      1bd81f6b
  20. 14 Dec, 2010 1 commit
    • Gleb Shchepa's avatar
      backport of bug #54476 fix from 5.1-bugteam to 5.0-bugteam. · 086130e3
      Gleb Shchepa authored
      Original revid: alexey.kopytov@sun.com-20100723115254-jjwmhq97b9wl932l
      
       > Bug #54476: crash when group_concat and 'with rollup' in
       >                      prepared statements
       >
       > Using GROUP_CONCAT() together with the WITH ROLLUP modifier
       > could crash the server.
       >
       > The reason was a combination of several facts:
       >
       > 1. The Item_func_group_concat class stores pointers to ORDER
       > objects representing the columns in the ORDER BY clause of
       > GROUP_CONCAT().
       >
       > 2. find_order_in_list() called from
       > Item_func_group_concat::setup() modifies the ORDER objects so
       > that their 'item' member points to the arguments list
       > allocated in the Item_func_group_concat constructor.
       >
       > 3. In some cases (e.g. in JOIN::rollup_make_fields) a copy of
       > the original Item_func_group_concat object could be created by
       > using the Item_func_group_concat::Item_func_group_concat(THD
       > *thd, Item_func_group_concat *item) copy constructor. The
       > latter essentially creates a shallow copy of the source
       > object. Memory for the arguments array is allocated on
       > thd->mem_root, but the pointers for arguments and ORDER are
       > copied verbatim.
       >
       > What happens in the test case is that when executing the query
       > for the first time, after a copy of the original
       > Item_func_group_concat object has been created by
       > JOIN::rollup_make_fields(), find_order_in_list() is called for
       > this new object. It then resolves ORDER BY by modifying the
       > ORDER objects so that they point to elements of the arguments
       > array which is local to the cloned object. When thd->mem_root
       > is freed upon completing the execution, pointers in the ORDER
       > objects become invalid. Those ORDER objects, however, are also
       > shared with the original Item_func_group_concat object which is
       > preserved between executions of a prepared statement. So the
       > first call to find_order_in_list() for the original object on
       > the second execution tries to dereference an invalid pointer.
       >
       > The solution is to create copies of the ORDER objects when
       > copying Item_func_group_concat to not leave any stale pointers
       > in other instances with different lifecycles.
      
      
      mysql-test/r/func_gconcat.result:
        Test case for bug #54476.
      mysql-test/t/func_gconcat.test:
        Test case for bug #54476.
      sql/item_sum.cc:
        Copy the ORDER objects pointed to by the elements of the
        'order' array in the copy constructor of
        Item_func_group_concat.
      sql/table.h:
        Removed the unused 'item_copy' member of the ORDER class.
      086130e3
  21. 08 Dec, 2010 1 commit
  22. 03 Dec, 2010 1 commit
  23. 30 Nov, 2010 2 commits
  24. 29 Nov, 2010 2 commits
  25. 24 Nov, 2010 4 commits
    • Gleb Shchepa's avatar
      backport of bug #54461 from 5.1-security to 5.0-security · a30e9dda
      Gleb Shchepa authored
       > revision-id: gshchepa@mysql.com-20100801181236-uyuq6ewaq43rw780
       > parent: alexey.kopytov@sun.com-20100723115254-jjwmhq97b9wl932l
       > committer: Gleb Shchepa <gshchepa@mysql.com>
       > branch nick: mysql-5.1-security
       > timestamp: Sun 2010-08-01 22:12:36 +0400
       > Bug #54461: crash with longblob and union or update with subquery
       >
       > Queries may crash, if
       >   1) the GREATEST or the LEAST function has a mixed list of
       >      numeric and LONGBLOB arguments and
       >   2) the result of such a function goes through an intermediate
       >      temporary table.
       >
       > An Item that references a LONGBLOB field has max_length of
       > UINT_MAX32 == (2^32 - 1).
       >
       > The current implementation of GREATEST/LEAST returns REAL
       > result for a mixed list of numeric and string arguments (that
       > contradicts with the current documentation, this contradiction
       > was discussed and it was decided to update the documentation).
       >
       > The max_length of such a function call was calculated as a
       > maximum of argument max_length values (i.e. UINT_MAX32).
       >
       > That max_length value of UINT_MAX32 was used as a length for
       > the intermediate temporary table Field_double to hold
       > GREATEST/LEAST function result.
       >
       > The Field_double::val_str() method call on that field
       > allocates a String value.
       >
       > Since an allocation of String reserves an additional byte
       > for a zero-termination, the size of String buffer was
       > set to (UINT_MAX32 + 1), that caused an integer overflow:
       > actually, an empty buffer of size 0 was allocated.
       >
       > An initialization of the "first" byte of that zero-size
       > buffer with '\0' caused a crash.
       >
       > The Item_func_min_max::fix_length_and_dec() has been
       > modified to calculate max_length for the REAL result like
       > we do it for arithmetical operators.
      
      
      mysql-test/r/func_misc.result:
        Test case for bug #54461.
      mysql-test/t/func_misc.test:
        Test case for bug #54461.
      sql/item_func.cc:
        Bug #54461: crash with longblob and union or update with subquery
        
        The Item_func_min_max::fix_length_and_dec() has been
        modified to calculate max_length for the REAL result like
        we do it for arithmetical operators.
      a30e9dda
    • Alexander Nozdrin's avatar
      A follow-up for Bug#58339 (Replace Server GPL README file). · 14b38121
      Alexander Nozdrin authored
      Fix formatting issues in README file.
      14b38121
    • Alexander Nozdrin's avatar
      Merge from mysql-5.0-bugteam. · 523a4745
      Alexander Nozdrin authored
      523a4745
    • Alexander Nozdrin's avatar
      A follow-up for Bug#58340 (Remove Server GPL EXCEPTIONS-CLIENT file) -- remove all · 85f855e0
      Alexander Nozdrin authored
      EXCEPTIONS-CLIENT from all the places.
      85f855e0
  26. 23 Nov, 2010 1 commit
  27. 22 Nov, 2010 3 commits
    • Gleb Shchepa's avatar
      backport: Bug #55568 from 5.1-security to 5.0-security · 47bb750c
      Gleb Shchepa authored
      > revision-id: alexey.kopytov@sun.com-20100824103548-ikm79qlfrvggyj9h
      > parent: sunny.bains@oracle.com-20100816001222-xqc447tr6jwh8c53
      > committer: Alexey Kopytov <Alexey.Kopytov@Sun.com>
      > branch nick: 5.1-security
      > timestamp: Tue 2010-08-24 14:35:48 +0400
      > message:
      >   Bug #55568: user variable assignments crash server when used
      >               within query
      >   
      >   The server could crash after materializing a derived table
      >   which requires a temporary table for grouping.
      >   
      >   When destroying the temporary table used to execute a query for
      >   a derived table, JOIN::destroy() did not clean up Item_fields
      >   pointing to fields in the temporary table. This led to
      >   dereferencing a dangling pointer when printing out the items
      >   tree later in the outer SELECT.
      >   
      >   The solution is an addendum to the patch for bug37362: in
      >   addition to cleaning up items in tmp_all_fields3, do the same
      >   for items in tmp_all_fields1, since now we have an example
      >   where this is necessary.
      
      
      sql/field.cc:
        Make sure field->table_name is not set to NULL in
        Field::make_field() to avoid assertion failure in 
        Item_field::make_field() after cleaning up items
        (the assertion fired in udf.test when running
        the test suite with the patch applied).
      sql/sql_select.cc:
        In addition to cleaning up items in tmp_all_fields3, do the
        same for items in tmp_all_fields1.
        Introduce a new helper function to avoid code duplication.
      sql/sql_select.h:
        Introduce a new helper function to avoid code duplication in
        JOIN::destroy().
      47bb750c
    • Alexander Nozdrin's avatar
    • Alexander Nozdrin's avatar