MySQL Bugs: #79807: Workbench Data Export: Unhandled exception: Error querying security information

Bug #79807	Workbench Data Export: Unhandled exception: Error querying security information
Submitted:	29 Dec 2015 16:07	Modified:	21 Jan 2017 19:42
Reporter:	François Gagné	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Workbench: Administration	Severity:	S2 (Serious)
Version:	6.3.6	OS:	Any
Assigned to:		CPU Architecture:	Any

Description:
In MySQL Workbench, Data Export, when clicking "Start Export", an error dialog is shown stating there was an "Unhandled exception: Error querying security information" see below for the full message. The "Start Export" is greyed out, it's impossible to continue. This is a regression from 6.3.5. It appears the problem arise if connecting with an user with no privileges on the mysql schema.

Unhandled exception: Error querying security information: Error executing 'SELECT * FROM mysql.user WHERE User='[REMOVED]' AND Host='[REMOVED]' ORDER BY User, Host'
SELECT command denied to user '[REMOVED]'@'[REMOVED]' for table 'user'.
SQL Error: 1142

How to repeat:
1) Connect to the database with an user with no privileges on the mysql schema
2) Navigate to "Data Export"
3) Select a table to export
4) Click the "Start Export" button

Suggested fix:
Give a warning about the error and allow to continue with data export.

The code should be checked to know exactly why "security information" is needed. If security information is absolutely necessary, verify if there is another way to acquire the information. Also, if the "security information" is useful only if a given options is selected, only query the "security information" if the selected options are checked.

exception dialog

Attachment: user.png (image/png, text), 238.42 KiB.

Thank you for the bug report.

Same here, this affects almost any shared hosting in the world, and I don't find an easy way to rollback to the 3.6.5 (the "previous GA version" that can be downloaded from the official website is the 6.2.5)

My error dialog when trying to export data

Attachment: Untitled.png (image/png, text), 3.99 KiB.

I have been having a similar problem.  Started with me not beinga able to press the "Start Export" button (it did nothing).  I re-installed from 6.3.5 to 6.3.6 and now I can't even get to the Data Export page (I just posted a picture of the error dialog I get).

I am running Windows 10 32 bit

Justin Levene error message is about: global name 'self' is not defined.

This seems unrelated to this particular bug about querying security information.

I would suggest searching/opening a new bug.

Downgraded to 6.3.4 and error dialog didn't appear.

The Start Export Button wasn't working because I was on MYSQL 5.6 and upgraded to 5.7, but MYSQL Workbench kept the setting for the file in the 5.6 directory.

This bugged me too, because I needed to install Visual Studio 2015 CE and this required me to update Mysql. In the end the workaround is simple - for me in any case. Install Mysql from the latest installer (mysql-installer-community-5.7.11.0 in my case), then manually uninstall Workbench and manually re-install a slightly older version of workbench (mysql-workbench-community-6.3.4-winx64).Problem not solved, but symptoms dealt with.

Could you please fix this.  We have a number of shared hosting sites to manage and this new upgrade makes it impossible to export databases.  We tried to go to a release older but we could not fine 6.3.4 so had to go back to 6.2.5.0 since that was the only older version we found listed under "older versions"

Thanks in advance for any help with this.

Here's the link to download archived versions of MySQL Workbench:
https://downloads.mysql.com/archives/workbench/

Bug #80214 marked as duplicate of this

Fix confirmed 6.3.7. In the same environment, 6.3.6 show the issue, 6.3.7 doesn't.

Posted by developer:
 
Fixed as of the upcoming MySQL Workbench 6.3.9 release, and here's the changelog entry:

The Export Data operation emitted an unhandled exception when the user
connecting to the server lacked privileges on the mysql schema, but had
full privileges on the database identified by the operation.

Thank you for the bug report.