1. 04 Jan, 2018 1 commit
  2. 03 Jan, 2018 2 commits
  3. 02 Jan, 2018 3 commits
  4. 28 Dec, 2017 1 commit
  5. 27 Dec, 2017 2 commits
  6. 22 Dec, 2017 1 commit
  7. 21 Dec, 2017 2 commits
    • Vicențiu Ciorbaru's avatar
      Follow up to MDEV-12366: FLUSH privileges can break hierarchy of roles · 24efee91
      Vicențiu Ciorbaru authored
      A suggestion to make role propagation simpler from serg@mariadb.org.
      
      Instead of gathering the leaf roles in an array, which for very wide
      graphs could potentially mean a big part of the whole roles schema, keep
      the previous logic. When finally merging a role, set its counter
      to something positive.
      
      This will effectively mean that a role has been merged, thus a random pass
      through roles hash that touches a previously merged role won't cause the problem
      described in MDEV-12366 any more, as propagate_role_grants_action will stop
      attempting to merge from that role.
      24efee91
    • Marko Mäkelä's avatar
      MDEV-12827 Assertion failure when reporting duplicate key error in online table rebuild · 0202e472
      Marko Mäkelä authored
      row_log_table_apply_insert_low(), row_log_table_apply_update():
      When reporting the error_key_num, only count the clustered index
      if it corresponds to a key in the SQL layer.
      
      The assertion failure was probably introduced by the (incomplete)
      MySQL 5.6.28 bug fix
      Bug #21364096 THE BOGUS DUPLICATE KEY ERROR IN ONLINE DDL
      WITH INCORRECT KEY NAME
      which we are improving.
      
      Side note: the fix was incorrectly merged to MySQL 5.7.10;
      incorrect key names will continue to be reported in MySQL 5.7.
      0202e472
  8. 20 Dec, 2017 4 commits
  9. 19 Dec, 2017 3 commits
    • Simon J Mudd's avatar
    • Vicențiu Ciorbaru's avatar
      MDEV-12366: FLUSH PRIVILEGES can break hierarchy of roles · be758322
      Vicențiu Ciorbaru authored
      Whenever we call merge_role_privileges on a role, we make use of
      the role->counter variable to check if all it's children have had their
      privileges merged. Only if all children have had their privileges merged,
      do we update the privileges on parent. This is done to prevent extra work.
      The same idea is employed during flush privileges. You only begin merging
      from "leaf" roles. The recursive calls will merge their parents at some point.
      A problem arises when we try to "re-merge" a parent. Take the following graph:
      
      {noformat}
           A (0)  ----  C (2) ---- D (2)  ---- USER
                       /          /
           B (0)  ----/          /
                                /
           E (0) --------------/
      {noformat}
      
      In parentheses we have the "counter" value right before we start to iterate
      through the roles hash and propagate values. It represents the number of roles
      granted to the current role. The order in which we iterate through the roles
      hash is alphabetical.
      
      * First merge A, which leads to decreasing the counter for C to 1. Since C is
      not 0, we don't proceed with merging into C.
      
      * Second we merge B, which leads to decreasing the counter for C to 0. Now
      we proceed with merging into C. This leads to reducing the counter for D to 1
      as part of C merge process.
      
      * Third as we iterate through the hash, we see that C has counter 0, thus we
      start the merge process *again*. This leads to reducing the counter for
      D to 0! We then attempt to merge D.
      
      * Fourth we start merging E. When E sees D as it's parent (according to the code)
      it attempts to reduce D's counter, which leads to overflow. Now D's counter is
      a very large number, thus E's privileges are not forwarded to D yet.
      
      To correct this behavior we must make sure to only start merging from initial
      leaf nodes.
      be758322
    • Vicențiu Ciorbaru's avatar
      MDEV-13655: Set role does not properly grant privileges. · 2fced9e7
      Vicențiu Ciorbaru authored
      When granting a role to another role, DB privileges get propagated. If
      the grantee had no previous DB privileges, an extra ACL_DB entry is created to
      house those "indirectly received" privileges. If, afterwards, DB
      privileges are granted to the grantee directly, we must make sure to not
      create a duplicate ACL_DB entry.
      2fced9e7
  10. 18 Dec, 2017 3 commits
  11. 16 Dec, 2017 1 commit
  12. 13 Dec, 2017 5 commits
  13. 08 Dec, 2017 1 commit
  14. 06 Dec, 2017 1 commit
  15. 05 Dec, 2017 1 commit
  16. 30 Nov, 2017 1 commit
  17. 22 Nov, 2017 1 commit
  18. 20 Nov, 2017 1 commit
  19. 16 Nov, 2017 5 commits
  20. 15 Nov, 2017 1 commit