Pre-General Availability Draft: 2017-07-17
The mysql_no_login server-side authentication
plugin prevents all client connections to any account that uses
it. Use cases for such a plugin includes accounts that must be
able to execute stored programs and views with elevated
privileges without exposing those privileges to ordinary users,
and proxied accounts that should never permit direct login but
are accessed only through proxy accounts.
The following table shows the plugin and library file names. The
file name suffix might differ on your system. The file must be
located in the directory named by the
plugin_dir system variable.
Table 6.13 Plugin and Library Names for “No Login” Authentication
| Server-side plugin name | mysql_no_login |
| Client-side plugin name | None |
| Library file name | mysql_no_login.so |
The following sections provide installation and usage information specific to no-login pluggable authentication:
For general information about pluggable authentication in MySQL, see Section 6.3.10, “Pluggable Authentication”. For proxy user information, see Section 6.3.11, “Proxy Users”.
This section describes how to install the no-login authentication plugin. For general information about installing plugins, see Section 5.6.2, “Installing and Uninstalling Plugins”.
To be usable by the server, the plugin library file must be
located in the MySQL plugin directory (the directory named by
the plugin_dir system
variable). If necessary, set the value of
plugin_dir at server startup
to tell the server the plugin directory location.
The plugin library file base name is
mysql_no_login. The file name suffix
differs per platform (for example, .so
for Unix and Unix-like systems, .dll for
Windows).
To load the plugin at server startup, use the
--plugin-load-add option to
name the library file that contains it. With this
plugin-loading method, the option must be given each time the
server starts. For example, put these lines in your
my.cnf file (adjust the
.so suffix for your platform as
necessary):
[mysqld]
plugin-load-add=mysql_no_login.so
After modifying my.cnf, restart the
server to cause the new settings to take effect.
Alternatively, to register the plugin at runtime, use this statement (adjust the extension as necessary):
INSTALL PLUGIN mysql_no_login SONAME 'mysql_no_login.so';
INSTALL PLUGIN loads a plugin,
and also registers it in the mysql.plugins
system table to cause the plugin to be loaded for each
subsequent normal server startup.
To verify plugin installation, examine the
INFORMATION_SCHEMA.PLUGINS table
or use the SHOW PLUGINS
statement (see
Section 5.6.3, “Obtaining Server Plugin Information”). For example:
mysql> SELECT PLUGIN_NAME, PLUGIN_STATUS
FROM INFORMATION_SCHEMA.PLUGINS
WHERE PLUGIN_NAME LIKE '%login%';
+----------------+---------------+
| PLUGIN_NAME | PLUGIN_STATUS |
+----------------+---------------+
| mysql_no_login | ACTIVE |
+----------------+---------------+If the plugin fails to initialize, check the server error log for diagnostic messages.
To associate MySQL accounts with the no-login plugin, see Using No-Login Pluggable Authentication.
The method used to uninstall the no-login authentication plugin depends on how you installed it:
If you installed the plugin at server startup using a
--plugin-load-addoption, restart the server without the option.If you installed the plugin at runtime using
INSTALL PLUGIN, it remains installed across server restarts. To uninstall it, useUNINSTALL PLUGIN:UNINSTALL PLUGIN mysql_no_login;
This section describes how to use the no-login authentication plugin to prevent connections from MySQL client programs to the server. It is assumed that the server is running with the server-side plugin enabled, as described in Installing No-Login Pluggable Authentication.
To refer to the no-login authentication plugin in the
IDENTIFIED WITH clause of a
CREATE USER statement, use the
name mysql_no_login.
An account that authenticates using
mysql_no_login may be used as the
DEFINER for stored program and view
objects. If such an object definition also includes
SQL SECURITY DEFINER, it executes with that
account's privileges. DBAs can use this behavior to provide
access to confidential or sensitive data that is exposed only
through well-controlled interfaces.
The following example provides a simple illustration of these
principles. It defines an account that does not permit client
connections, and associates with it a view that exposes only
certain columns of the mysql.user table:
CREATE DATABASE nologindb;
CREATE USER 'nologin'@'localhost'
IDENTIFIED WITH mysql_no_login;
GRANT ALL ON nologindb.*
TO 'nologin'@'localhost';
GRANT SELECT ON mysql.user
TO 'nologin'@'localhost';
CREATE DEFINER = 'nologin'@'localhost'
SQL SECURITY DEFINER
VIEW nologindb.myview
AS SELECT User, Host FROM mysql.user;To provide protected access to the view to an ordinary user, do this:
GRANT SELECT ON nologindb.myview
TO 'ordinaryuser'@'localhost';Now the ordinary user can use the view to access the limited information it presents:
SELECT * FROM nologindb.myview;Attempts by the user to access columns other than those exposed by the view result in an error, as do all attempts to select from the view by users not granted access to it.
Because the nologin account cannot be
used directly, the operations required to set up objects
that it uses must be performed by root or
similar account with the privileges required to create the
objects and set DEFINER values.
An account that authenticates using
mysql_no_login may be used as a proxied
base user for proxy accounts:
-- create proxied account
CREATE USER 'proxy_base'@'localhost'
IDENTIFIED WITH mysql_no_login;
-- grant privileges to proxied account
GRANT ... TO 'proxy_base'@'localhost';
-- permit real_user to be proxy for proxied account
GRANT PROXY ON 'proxy_base'@'localhost'
TO 'real_user'@'localhost';
This enables clients to access MySQL through the proxy account
(real_user) but not to bypass the proxy
mechanism by connecting directly as the proxied user
(proxy_base).