1. 06 Oct, 2011 1 commit
  2. 29 Sep, 2011 2 commits
    • Tatjana Azundris Nuernberg's avatar
      manual merge · 7944320f
      Tatjana Azundris Nuernberg authored
      7944320f
    • Tatjana Azundris Nuernberg's avatar
      Bug#11765687 (MySQL58677): No privilege on table / view, but can know #rows /... · 8932ae21
      Tatjana Azundris Nuernberg authored
      Bug#11765687 (MySQL58677): No privilege on table / view, but can know #rows / underlying table's name
      
      1 - If a user had SHOW VIEW and SELECT privileges on a view and
      this view was referencing another view, EXPLAIN SELECT on the outer
      view (that the user had privileges on) could reveal the structure
      of the underlying "inner" view as well as the number of rows in
      the underlying tables, even if the user had privileges on none of
      these referenced objects.
      
      This happened because we used DEFINER's UID ("SUID") not just for
      the view given in EXPLAIN, but also when checking privileges on
      the underlying views (where we should use the UID of the EXPLAIN's
      INVOKER instead).
      
      We no longer run the EXPLAIN SUID (with DEFINER's privileges).
      This prevents a possible exploit and makes permissions more
      orthogonal.
      
      2 - EXPLAIN SELECT would reveal a view's structure even if the user
      did not have SHOW VIEW privileges for that view, as long as they
      had SELECT privilege on the underlying tables.
      
      Instead of requiring both SHOW VIEW privilege on a view and SELECT
      privilege on all underlying tables, we were checking for presence
      of either of them.
      
      We now explicitly require SHOW VIEW and SELECT privileges on
      the view we run EXPLAIN SELECT on, as well as all its
      underlying views. We also require SELECT on all relevant
      tables. 
      
      
      mysql-test/r/view_grant.result:
        add extensive tests to illustrate desired behavior and
        prevent regressions (as always).
      mysql-test/t/view_grant.test:
        add extensive tests to illustrate desired behavior and
        prevent regressions (as always).
      sql/sql_view.cc:
        We no longer run the EXPLAIN SUID (with DEFINER's privileges).
        To achieve this, we use a temporary, SUID-less TABLE_LIST for
        the views while checking privileges.
      8932ae21
  3. 23 Sep, 2011 1 commit
  4. 22 Sep, 2011 1 commit
    • Alexander Nozdrin's avatar
      Fix for Bug#13001491: MYSQL_REFRESH CRASHES WHEN STORED ROUTINES ARE RUN CONCURRENTLY. · 1922d65f
      Alexander Nozdrin authored
      The main problem was that lex_start() was forgotten to be called before processing
      COM_REFRESH.
      
      Another problem discovered was that if failures to flush the error log were not properly
      handled, which resulted in the server crash.
      
      The user-visible effect of these problems were:
        - if COM_REFRESH command was sent after SQL-queries of some sort,
          the server would crash.
        - if COM_REFRESH was requested with REFRESH_LOG only, and the error log
          failed to flush, the server would crash. The error log fails to flush
          when it points to unavailable file (for example, due to restricted
          permissions).
      
      The fixes are:
        - call lex_start() in the beginning of COM_REFRESH;
        - handle failures to flush the error log properly, i.e. raise ER_UNKNOWN_ERROR.
      
      sql/sql_parse.cc:
        Fix for Bug#13001491: MYSQL_REFRESH CRASHES WHEN STORED ROUTINES ARE RUN CONCURRENTLY.
      tests/mysql_client_test.c:
        A test case for Bug#13001491: MYSQL_REFRESH CRASHES WHEN STORED ROUTINES
        ARE RUN CONCURRENTLY.
      1922d65f
  5. 15 Sep, 2011 6 commits
  6. 06 Sep, 2011 1 commit
  7. 24 Aug, 2011 1 commit
  8. 23 Aug, 2011 2 commits
  9. 19 Aug, 2011 1 commit
  10. 17 Aug, 2011 3 commits
  11. 13 Aug, 2011 1 commit
    • Dmitry Shulga's avatar
      Fixed Bug#12621017 - CRASH IF A SP VARIABLE IS USED IN THE LIMIT CLAUSE OF A · 644db664
      Dmitry Shulga authored
      SET STATEMENT.
      
      Server built with debug asserts, without debug crashes if a user tries
      to run a stored procedure that constains query with subquery that include
      either LIMIT or LIMIT OFFSET clauses.
      
      The problem was that Item::fix_fields() was not called for the items
      representing LIMIT or OFFSET clauses.
      
      The solution is to call Item::fix_fields() right before evaluation in
      st_select_lex_unit::set_limit().
      
      mysql-test/r/sp.result:
        Added testcase result for bug#12621017. Updated testcase result for
        bug 11918.
      mysql-test/t/sp.test:
        Added testcase for bug#12621017. Addressed review comments for Bug 11918
        (added tests for use LIMIT at stored function).
      sql/item.h:
        Addressed review comments for Bug 11918.
      sql/share/errmsg-utf8.txt:
        Addressed review comments for Bug 11918.
      sql/sp_head.cc:
        Addressed review comments for Bug 11918.
      sql/sql_lex.cc:
        Added call fix_fields() for item just before its evaluation.
      sql/sql_yacc.yy:
        Addressed review comments for Bug 11918.
      644db664
  12. 12 Aug, 2011 4 commits
    • Georgi Kodinov's avatar
      merge · 232b112e
      Georgi Kodinov authored
      232b112e
    • Georgi Kodinov's avatar
      Bug #11765565: 58548: 5.5.X NEEDS TO LINK TO THE CORESERVICES FRAMEWORK · 0d6a4b08
      Georgi Kodinov authored
        FOR SOME PLUGINS TO WORK
      
      Some dynamically loadable plugins on the Mac may need functions from the 
      CoreServices framework. Unfortunately the only place where this can be initialized
      is the main executable. Thus to allow plugins to use functions from that framework
      the mysqld binary needs to link to the framework.
      0d6a4b08
    • Georgi Kodinov's avatar
      Bug #12818542: PAM: ADDING PASSWORD FOR AN ACCOUNT DISABLES · 4d0784ee
      Georgi Kodinov authored
      PAM AUTHENTICATION SETTINGS
      
      SET PASSWORD code on a account with plugin authentication was errorneously
      resetting the in-memory plugin pointer for the user back to native password 
      plugin despite the fact that it was sending a warning that the command has 
      no immediate effect.
      Fixed by not updating the user's plugin if it's already set to a non default value.
      Note that the bug affected only the in-memory cache of the user definitions.
      Any restart of the server will fix the problem.
      Also the salt and the password has are still stored into the user tables (just as 
      it's documented now).
      Test case added.
      One old test case result updated  to have the correct value.
      4d0784ee
    • Georgi Kodinov's avatar
      bumped up the version to 5.5.18 · 5a7e0127
      Georgi Kodinov authored
      5a7e0127
  13. 11 Aug, 2011 1 commit
  14. 10 Aug, 2011 4 commits
  15. 09 Aug, 2011 3 commits
  16. 08 Aug, 2011 2 commits
  17. 05 Aug, 2011 1 commit
  18. 03 Aug, 2011 1 commit
    • Gleb Shchepa's avatar
      backport from mysql-trunk · 22c2d06d
      Gleb Shchepa authored
      BUG #11754979 - 46675: ON DUPLICATE KEY UPDATE AND UPDATECOUNT() POSSIBLY WRONG 
      
      The mysql_affected_rows() client call returns 3 instead of 2 on
      INSERT ... ON DUPLICATE KEY UPDATE query with a duplicated key value.
      
      The fix for the old bug #29692 was incomplete: unnecessary double
      increment of "touched" rows still happened.
      
      This bugfix removes:
      1) unneeded increment of "touched" rows and
      2) useless double resetting of auto-increment value.
      
      
      sql/sql_insert.cc:
        write_record() function:
        Unneeded increment of "touched" rows and useless double resetting
        of auto-increment value has been removed.
      tests/mysql_client_test.c:
        New test case.
      22c2d06d
  19. 02 Aug, 2011 2 commits
    • Sergey Glukhov's avatar
      5.1 -> 5.5 merge · 53fb954d
      Sergey Glukhov authored
      53fb954d
    • Sergey Glukhov's avatar
      Bug#11766594 59736: SELECT DISTINCT.. INCORRECT RESULT WITH DETERMINISTIC FUNCTION IN WHERE C · 3468b55a
      Sergey Glukhov authored
      There is an optimization of DISTINCT in JOIN::optimize()
      which depends on THD::used_tables value. Each SELECT statement
      inside SP resets used_tables value(see mysql_select()) and it
      leads to wrong result. The fix is to replace THD::used_tables
      with LEX::used_tables.
      
      
      mysql-test/r/sp.result:
        test case
      mysql-test/t/sp.test:
        test case
      sql/sql_base.cc:
        THD::used_tables is replaced with LEX::used_tables
      sql/sql_class.cc:
        THD::used_tables is replaced with LEX::used_tables
      sql/sql_class.h:
        THD::used_tables is replaced with LEX::used_tables
      sql/sql_insert.cc:
        THD::used_tables is replaced with LEX::used_tables
      sql/sql_lex.cc:
        THD::used_tables is replaced with LEX::used_tables
      sql/sql_lex.h:
        THD::used_tables is replaced with LEX::used_tables
      sql/sql_prepare.cc:
        THD::used_tables is replaced with LEX::used_tables
      sql/sql_select.cc:
        THD::used_tables is replaced with LEX::used_tables
      3468b55a
  20. 28 Jul, 2011 1 commit
  21. 27 Jul, 2011 1 commit