Adding option for ‘read-only’ connections in SQLyog MySQL GUI 12.4

This release introduces a new major feature – ‘read-only’ connections – as well as Kerberos authentication support and a few bug fixes.

Changes as compared to MySQL GUI 12.3.3 include:


* Added an option for defining a connection as ‘read-only’.  There is a checkbox in the connection settings and when checked the title bar will inform user about the ‘read-only’ state. In ‘read-only’ state statements that write cannot be executed. For more details please see note at the bottom.
* Added support for the MariaDB auth_gssapi (Kerberos) plugin. This plugin is available with the latest 3.0 (alpha) Connector/C from MariaDB. But there seems to  be a huge popular demand for this already, and we have backported it to the 2.3 connector version we use in SQLyog.  Note that support for this plugin is not available with SJA for Linux with this release.

Bug Fixes:

* In User Manager, if a MySQL username contained certain special characters (including  “@”),  it was not possible to GRANT privileges TO or  DROP the user due to misplaced quotes in the generated SQL.
* Adding a new user in the ‘User Manager’ wasn’t populating the the newly added user_name in the ‘User’ field.
* On localized keyboards with an ALTGR key, this key unintentionally behaved like CTRL with autocomplete popups. With some such keyboards using a non-QWERTY layout, this could prevent typing of specific characters.

A note about ‘read-only’ connections:

With the read-only flag checked in the settings for a connection, ‘read-only’ is enforced client-side from the SQLyog GUI and the editor no matter if user’s server-side privileges allows for writes. In ‘read-only mode’ you will be able to retrieve data from the server, use user variables, define SESSION-scope of server variables and everything else you need to work with data as long as you don’t need to write to the server.

In the GUI, controls that trigger statements that write to the database are ‘greyed out’ and do nothing. In the editor the same statements will be caught and not sent. This is accomplished by filtering against a ‘positive list’ of statements that are allowed. They are SHOW, SELECT, DO, DESCRIBE, EXPLAIN, USE, SET (except for SET GLOBAL|SET @@GLOBAL..), HELP, HANDLER, CHECK, ANALYZE, OPTIMIZE as well all transactional statements.

Further we also allow for CALL and please observe that ‘read-only mode’ is not enforced when executing a Stored Procedure or Function. It is also not enforced in the SJA – no matter whether launching an SJA-job from the GUI or from command-line. The SJA simply does not read this flag.

For the reasons above – and also because any user can easily turn the ‘read-only’ flag OFF – you should not consider this feature a ‘security feature’ (not a bullet-proof one, at least), but rather a ‘convenience feature’: With this flag ON, you will not accidentially (due to distraction, accidentially clicking with the mouse the wrong place or whatever) execute a statement that writes to the database. You are maybe not ‘fully secure’, but you are ‘safe’.

The ‘read-only’ feature is available in Professional, Enterprise and Ultimate editions of SQLyog.