1. 10 Oct, 2006 1 commit
    • kroki/tomash@moonlight.intranet's avatar
      Bug#19111: TRIGGERs selecting from a VIEW on the firing base table fail. · 4a28f8f1
      kroki/tomash@moonlight.intranet authored
      In a trigger or a function used in a statement it is possible to do
      SELECT from a table being modified by the statement.  However,
      encapsulation of such SELECT into a view and selecting from a view
      instead of direct SELECT was not possible.
      
      This happened because tables used by views (which in their turn
      were used from functions/triggers) were not excluded from checks
      in unique_table() routine as it happens for the rest of tables
      added to the statement table list for prelocking.
      
      With this fix we ignore all such tables in unique_table(), thus
      providing consistency: inside a trigger or a functions SELECT from
      a view may be used where plain SELECT is allowed.  Modification of
      the same table from function or trigger is still disallowed.  Also,
      this patch doesn't affect the case where SELECT from the table being
      modified is done outside of function of trigger, such SELECTs are
      still disallowed (this limitation and visibility problem when function
      select from a table being modified are subjects of bug 21326).  See
      also bug 22427.
      4a28f8f1
  2. 24 Jul, 2006 3 commits
    • kroki/tomash@moonlight.intranet's avatar
      Merge moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0 · 6d05e32d
      kroki/tomash@moonlight.intranet authored
      into  moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0-bug14702
      6d05e32d
    • kroki/tomash@moonlight.intranet's avatar
      BUG#14702: misleading error message when syntax error in · 89ea3b01
      kroki/tomash@moonlight.intranet authored
                 CREATE PROCEDURE
      
      The bug was fixed already.  This changeset adds a test case.
      89ea3b01
    • kostja@bodhi.local's avatar
      A fix and a test case for Bug#15752 "Lost connection to MySQL server · 2ce1a07c
      kostja@bodhi.local authored
      when calling a SP from C API"
      
      The bug was caused by lack of checks for misuse in mysql_real_query. 
      A stored procedure always returns at least one result, which is the 
      status of execution of the procedure itself.
      This result, or so-called OK packet, is similar to a result
      returned by INSERT/UPDATE/CREATE operations: it contains the overall
      status of execution, the number of affected rows and the number of
      warnings. The client test program attached to the bug did not read this 
      result and ivnoked the next query. In turn, libmysql had no check for 
      such scenario and mysql_real_query was simply trying to send that query 
      without reading the pending response, thus messing up the communication
      protocol.
      
      The fix is to return an error from mysql_real_query when it's called
      prior to retrieval of all pending results.
      2ce1a07c
  3. 21 Jul, 2006 1 commit
  4. 20 Jul, 2006 1 commit
  5. 17 Jul, 2006 2 commits
  6. 13 Jul, 2006 2 commits
    • kroki/tomash@moonlight.intranet's avatar
      Merge moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0 · a3ea06db
      kroki/tomash@moonlight.intranet authored
      into  moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0-bug18630
      a3ea06db
    • kroki/tomash@moonlight.intranet's avatar
      Bug#18630: Arguments of suid routine calculated in wrong security · 4272d1ef
      kroki/tomash@moonlight.intranet authored
                 context.
      
      Routine arguments were evaluated in the security context of the routine
      itself, not in the caller's context.
      
      The bug is fixed the following way:
      
        - Item_func_sp::find_and_check_access() has been split into two
          functions: Item_func_sp::find_and_check_access() itself only
          finds the function and check that the caller have EXECUTE privilege
          on it.  New function set_routine_security_ctx() changes security
          context for SUID routines and checks that definer have EXECUTE
          privilege too.
      
        - new function sp_head::execute_trigger() is called from
          Table_triggers_list::process_triggers() instead of
          sp_head::execute_function(), and is effectively just as the
          sp_head::execute_function() is, with all non-trigger related code
          removed, and added trigger-specific security context switch.
      
        - call to Item_func_sp::find_and_check_access() stays outside
          of sp_head::execute_function(), and there is a code in
          sql_parse.cc before the call to sp_head::execute_procedure() that
          checks that the caller have EXECUTE privilege, but both
          sp_head::execute_function() and sp_head::execute_procedure() call
          set_routine_security_ctx() after evaluating their parameters,
          and restore the context after the body is executed.
      4272d1ef
  7. 12 Jul, 2006 3 commits
  8. 11 Jul, 2006 8 commits
  9. 10 Jul, 2006 19 commits