Comment 4 for bug 916168

For the record:

mysql> SHOW GRANTS FOR CURRENT_USER\G

5.1
===

*************************** 1. row ***************************
Grants for test_user@%: GRANT SELECT, PROCESS, SUPER, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'test_user'@'%' IDENTIFIED BY PASSWORD '*F3A2A51A9B0F2BE2468926B4132313728C250DBF'
*************************** 2. row ***************************
Grants for test_user@%: GRANT ALL PRIVILEGES ON `percona`.* TO 'test_user'@'%'

5.5.21
======

*************************** 1. row ***************************
Grants for test_user@%: GRANT SELECT, PROCESS, SUPER, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'test_user'@'%' IDENTIFIED BY PASSWORD '*F3A2A51A9B0F2BE2468926B4132313728C250DBF'
*************************** 2. row ***************************
Grants for test_user@%: GRANT ALL PRIVILEGES ON `percona`.* TO 'test_user'@'%'

Identical grants, but:

mysql> USE percona; SHOW FULL COLUMNS FROM checksums\G

5.1
===

*************************** 1. row ***************************
     Field: db
      Type: char(64)
 Collation: latin1_swedish_ci
      Null: NO
       Key: PRI
   Default: NULL
     Extra:
Privileges: select,insert,update,references
   Comment:

5.5.21
======

*************************** 1. row ***************************
     Field: db
      Type: char(64)
 Collation: latin1_swedish_ci
      Null: NO
       Key: PRI
   Default: NULL
     Extra:
Privileges: select
   Comment:

So as Baron said in bug 916168, I'm just going to remove the privs check and let the tool either work or not, and if it doesn't, then the user will know without a doubt that they need to fix the user's privs.