1
0
mirror of https://github.com/MariaDB/server.git synced 2026-10-28 08:01:55 +03:00
Files
mariadb/scripts/sys_schema/procedures/ps_setup_show_enabled.sql
Oleksandr Byelkin 6c951fea5f MDEV-39993 Use CREATE OR REPLACE for sys schema routines
mariadb-upgrade silently dropped EXECUTE grants on sys schema stored
functions and procedures. The sys schema install scripts reinstalled
every routine with DROP FUNCTION/PROCEDURE IF EXISTS followed by
CREATE. DROP cascades to delete the routine's rows in
mysql.procs_priv, so any EXECUTE grant a DBA had issued on e.g.
sys.table_exists or sys.quote_identifier was lost every time
mariadb-upgrade reinstalled the sys schema, even though the routine
itself came back unchanged.

Fix: replace DROP ... IF EXISTS + CREATE with CREATE OR REPLACE in
all 53 sys_schema function/procedure files and in the two templates
(templates/function.sql, templates/procedure.sql) so future routines
follow the same pattern. CREATE OR REPLACE PROCEDURE/FUNCTION goes
through sp_drop_routine_internal(), which only deletes the
mysql.proc row and never reaches sp_revoke_privileges() (that is
only called from the explicit DROP PROCEDURE/FUNCTION statement),
so mysql.procs_priv is left untouched and existing grants survive.
This mirrors the pattern already used by sys schema views
(CREATE OR REPLACE ... VIEW, since MDEV-9077), which never had this
problem.

Four of the converted files (functions/format_path.sql,
functions/ps_is_account_enabled_57.sql,
procedures/ps_setup_reset_to_default.sql,
procedures/ps_trace_thread_57.sql) are not referenced by
scripts/sys_schema/CMakeLists.txt; they were converted anyway for
consistency and have no behavioural effect.

As a side effect, a pre-existing UDF whose name collides with a sys
routine name is no longer destroyed before the reinstall fails:
DROP FUNCTION IF EXISTS resolved the UDF namespace first, silently
dropping the UDF and then failing on ER_SP_ALREADY_EXISTS anyway;
CREATE OR REPLACE fails immediately on ER_UDF_EXISTS with the UDF
intact.

scripts/maria_add_gis_sp.sql.in and the sys_config triggers were
deliberately left untouched: the GIS procedures are only
re-installed at bootstrap time (mariadb-upgrade instead patches
their definer in place via UPDATE), and triggers carry no
procs_priv rows, so neither is on the code path this bug is about.

Added mysql-test/main/mysql_upgrade_sys_routine_grants.test, which
grants EXECUTE on sys.table_exists and sys.quote_identifier,
overwrites both routine bodies with a marker to prove the upgrade
actually reinstalls them (rather than the sys schema install being
skipped), runs mariadb-upgrade, and checks both that the grants
survived and that the real routine bodies came back.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-21 17:07:02 +02:00

165 lines
6.6 KiB
SQL

-- Copyright (c) 2014, 2016, Oracle and/or its affiliates. All rights reserved.
--
-- This program is free software; you can redistribute it and/or modify
-- it under the terms of the GNU General Public License as published by
-- the Free Software Foundation; version 2 of the License.
--
-- This program is distributed in the hope that it will be useful,
-- but WITHOUT ANY WARRANTY; without even the implied warranty of
-- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
-- GNU General Public License for more details.
--
-- You should have received a copy of the GNU General Public License
-- along with this program; if not, write to the Free Software
-- Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
DELIMITER $$
CREATE OR REPLACE DEFINER='mariadb.sys'@'localhost' PROCEDURE ps_setup_show_enabled (
IN in_show_instruments BOOLEAN,
IN in_show_threads BOOLEAN
)
COMMENT '
Description
-----------
Shows all currently enabled Performance Schema configuration.
Parameters
-----------
in_show_instruments (BOOLEAN):
Whether to print enabled instruments (can print many items)
in_show_threads (BOOLEAN):
Whether to print enabled threads
Example
-----------
mysql> CALL sys.ps_setup_show_enabled(TRUE, TRUE);
+----------------------------+
| performance_schema_enabled |
+----------------------------+
| 1 |
+----------------------------+
1 row in set (0.00 sec)
+---------------+
| enabled_users |
+---------------+
| \'%\'@\'%\' |
+---------------+
1 row in set (0.01 sec)
+-------------+---------+---------+-------+
| object_type | objects | enabled | timed |
+-------------+---------+---------+-------+
| EVENT | %.% | YES | YES |
| FUNCTION | %.% | YES | YES |
| PROCEDURE | %.% | YES | YES |
| TABLE | %.% | YES | YES |
| TRIGGER | %.% | YES | YES |
+-------------+---------+---------+-------+
5 rows in set (0.01 sec)
+---------------------------+
| enabled_consumers |
+---------------------------+
| events_statements_current |
| global_instrumentation |
| thread_instrumentation |
| statements_digest |
+---------------------------+
4 rows in set (0.05 sec)
+---------------------------------+-------------+
| enabled_threads | thread_type |
+---------------------------------+-------------+
| sql/main | BACKGROUND |
| sql/thread_timer_notifier | BACKGROUND |
| innodb/io_ibuf_thread | BACKGROUND |
| innodb/io_log_thread | BACKGROUND |
| innodb/io_read_thread | BACKGROUND |
| innodb/io_read_thread | BACKGROUND |
| innodb/io_write_thread | BACKGROUND |
| innodb/io_write_thread | BACKGROUND |
| innodb/page_cleaner_thread | BACKGROUND |
| innodb/srv_lock_timeout_thread | BACKGROUND |
| innodb/srv_error_monitor_thread | BACKGROUND |
| innodb/srv_monitor_thread | BACKGROUND |
| innodb/srv_master_thread | BACKGROUND |
| innodb/srv_purge_thread | BACKGROUND |
| innodb/srv_worker_thread | BACKGROUND |
| innodb/srv_worker_thread | BACKGROUND |
| innodb/srv_worker_thread | BACKGROUND |
| innodb/buf_dump_thread | BACKGROUND |
| innodb/dict_stats_thread | BACKGROUND |
| sql/signal_handler | BACKGROUND |
| sql/compress_gtid_table | FOREGROUND |
| root@localhost | FOREGROUND |
+---------------------------------+-------------+
22 rows in set (0.01 sec)
+-------------------------------------+-------+
| enabled_instruments | timed |
+-------------------------------------+-------+
| wait/io/file/sql/map | YES |
| wait/io/file/sql/binlog | YES |
...
| statement/com/Error | YES |
| statement/com/ | YES |
| idle | YES |
+-------------------------------------+-------+
210 rows in set (0.08 sec)
Query OK, 0 rows affected (0.89 sec)
'
SQL SECURITY INVOKER
DETERMINISTIC
READS SQL DATA
BEGIN
SELECT @@performance_schema AS performance_schema_enabled;
-- In 5.7.6 and later the setup_actors table has an ENABLED column to
-- specify whether the actor is enabled. Before that all actors matched
-- in the setup_actors table were enabled.
SELECT CONCAT('\'', user, '\'@\'', host, '\'') AS enabled_users
FROM performance_schema.setup_actors
WHERE enabled = 'YES'
ORDER BY enabled_users;
SELECT object_type,
CONCAT(object_schema, '.', object_name) AS objects,
enabled,
timed
FROM performance_schema.setup_objects
WHERE enabled = 'YES'
ORDER BY object_type, objects;
SELECT name AS enabled_consumers
FROM performance_schema.setup_consumers
WHERE enabled = 'YES'
ORDER BY enabled_consumers;
IF (in_show_threads) THEN
SELECT IF(name = 'thread/sql/one_connection',
CONCAT(processlist_user, '@', processlist_host),
REPLACE(name, 'thread/', '')) AS enabled_threads,
TYPE AS thread_type
FROM performance_schema.threads
WHERE INSTRUMENTED = 'YES' AND name <> 'thread/innodb/thread_pool_thread'
ORDER BY enabled_threads;
END IF;
IF (in_show_instruments) THEN
SELECT name AS enabled_instruments,
timed
FROM performance_schema.setup_instruments
WHERE enabled = 'YES'
ORDER BY enabled_instruments;
END IF;
END$$
DELIMITER ;