Skip to content
/ server Public

MDEV-38601 require FEDERATED ADMIN for SHOW CREATE SERVER#4743

Open
MooSayed1 wants to merge 1 commit intoMariaDB:11.8from
MooSayed1:MDEV-38601-show-create-server-priv
Open

MDEV-38601 require FEDERATED ADMIN for SHOW CREATE SERVER#4743
MooSayed1 wants to merge 1 commit intoMariaDB:11.8from
MooSayed1:MDEV-38601-show-create-server-priv

Conversation

@MooSayed1
Copy link

The Jira issue number for this PR is: MDEV-38601

Description

SHOW CREATE SERVER did not require any privilege — any authenticated user
could run it and see full server connection details including passwords stored
in mysql.servers.

-- Any user could run this without FEDERATED ADMIN:
SHOW CREATE SERVER srv;
-- Returns: CREATE SERVER `srv` ... OPTIONS (USER 'remote_user', PASSWORD 'secret', ...)

CREATE SERVER, ALTER SERVER, and DROP SERVER all correctly require
FEDERATED ADMIN privilege, but SHOW CREATE SERVER (introduced in MDEV-15696,
MariaDB 11.7) was missing the equivalent check.

The root cause is in sql/sql_parse.cc: the SQLCOM_SHOW_CREATE_SERVER case
had no check_global_access() call before dispatching to
mysql_show_create_server().

The fix: add check_global_access(thd, PRIV_STMT_CREATE_SERVER) at the top
of the SQLCOM_SHOW_CREATE_SERVER case, matching the identical pattern used
by SQLCOM_CREATE_SERVER, SQLCOM_ALTER_SERVER, and SQLCOM_DROP_SERVER.

Release Notes

SHOW CREATE SERVER now requires the FEDERATED ADMIN privilege.
Users without this privilege receive ERROR 42000: Access denied; you need (at least one of) the FEDERATED ADMIN privilege(s).

How can this PR be tested?

./mtr main.grant_server

The test creates a server as root, then verifies that an unprivileged user
receives ER_SPECIFIC_ACCESS_DENIED_ERROR on SHOW CREATE SERVER, and that
the same user succeeds after being granted FEDERATED ADMIN.

Basing the PR against the correct MariaDB version

This is a bug fix. SHOW CREATE SERVER was introduced in 11.7, and the
earliest affected maintained branch is 11.8, so this PR targets upstream/11.8.

PR quality check

  • I checked the CODING_STANDARDS.md file and my PR conforms to this where appropriate.
  • For any trivial modifications to the PR, I am ok with the reviewer making the changes themselves.

@gkodinov gkodinov added the External Contribution All PRs from entities outside of MariaDB Foundation, Corporation, Codership agreements. label Mar 6, 2026
Copy link
Member

@gkodinov gkodinov left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for your contribution! This is a preliminary review.

In addition to the below, please make sure your commit has a commit message complying with CODING_STANDARDS.md.

OPTIONS (USER 'remote_user', HOST 'localhost', PASSWORD 'secret', DATABASE 'test2');
CREATE USER user1@localhost IDENTIFIED BY '';
GRANT ALL PRIVILEGES ON *.* TO user1@localhost;
REVOKE FEDERATED ADMIN, SUPER ON *.* FROM user1@localhost;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why are you revoking SUPER as well? Would SUPER allow SHOW CREATE SERVER? If it would, please document that into the Jira and the commit message.
And also add tests please.

res= show_create_db(thd, lex);
break;
case SQLCOM_SHOW_CREATE_SERVER:
if (check_global_access(thd, PRIV_STMT_CREATE_SERVER))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not the final reviewer, but here's my two cents (feel free to ignore completely):

It usually is not a good idea to reuse privileges. This turns them into roles (guarding access to multiple operations vs guarding a single operation). I'd advocate to adding a different privilege, to go inline with the already very atomic privileges for CREATE, ALTER and DROP SERVER.

Ideally servers would be like any other SQL object and the privileges to them would not be global. But it's what it is: they are global.

If you absolutely must reuse any of the privileges, I'd suggest reusing ALTER or (DROP + CREATE). As this would be how you can reroute already existing code to new servers. But I'd definitely advise against this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

External Contribution All PRs from entities outside of MariaDB Foundation, Corporation, Codership agreements.

Development

Successfully merging this pull request may close these issues.

2 participants