MariaDB/MySQLのユーザー作成｜CREATE USERと最小権限のGRANT

CREATE USERとGRANTを分けてDBユーザーを作る

ここはMySQL/MariaDB配下のDBユーザー作成の記事です。OSのuseraddやsudoを実行するページではありません。DBアカウントを作るCREATE USERと、表への操作権限を付けるGRANTを分けると、「接続はできるがSELECTできない」状態も正しく判断できます。

先に決める4点

1. 操作するサーバーの製品/版と対象環境。管理接続先が本番と検体で混ざっていないか確認します。
2. 作成するuserと接続元host。hostは接続先サーバー名ではなく、サーバーが照合する接続元の条件です。
3. 既に存在しないか、同名の別hostアカウントがないか。存在した場合は削除/上書きではなく用途を確認します。
4. 必要な認証/TLS条件と対象DB・表・操作。既存アプリの秘密値や接続先を無断で変更しません。

接続先を読み取る

SELECT VERSION() AS server_version, USER() AS presented_identity,
       CURRENT_USER() AS matched_account, DATABASE() AS current_database;
SHOW GRANTS;

接続済みセッションの確認で、まだ認証できない接続を直すSQLではありません。SHOW GRANTSは管理者の権限を確認する手掛かりですが、MariaDBでは認証ハッシュを含む場合があるため出力全文を共有しません。管理者が作成できることと、新規利用者に管理者権限が必要なことは同じではありません。

隔離検体の作成例：まずアカウントだけ

以下は新しい使い捨てDBだけで動かした学習例です。cwiki_w23_sample.itemsには検体行が既にあります。公開パスワードは検証用で、実運用に使いません。localhostは検体内のUNIX socket接続用で、別コンテナや外部端末から同じ条件で接続できる例ではありません。実サーバーへの実行前に管理権限/既存名/接続元を別に確認してください。

-- Isolated fixture only. This public password is not a real credential.
CREATE USER 'cwiki_w23_reader'@'localhost'
  IDENTIFIED BY 'Cwiki_public_w23_only_42!';

この時点では接続してSELECT 1を実行できても、検体表の読取は拒否されました。CREATE USERはDBや表を作らず、対象表のSELECTを自動付与しません。空パスワード、%やALLを加えて原因を消す必要はありません。

対象表のSELECTだけを付与する

-- The fixture table exists already. Grant only its read operation.
GRANT SELECT ON cwiki_w23_sample.items TO 'cwiki_w23_reader'@'localhost';
SHOW GRANTS FOR 'cwiki_w23_reader'@'localhost';

管理接続で付与した後、新しい利用者として別接続し、次の読取を実行します。検体では両製品でid=1のpreserved、id=2のread onlyの2行が返りました。FLUSHなしで成功し、同じ利用者のINSERT/DELETEは1142で拒否されました。SELECT専用の設計で書込拒否は正常です。

SELECT id, label FROM cwiki_w23_sample.items ORDER BY id;

実際のアプリに必要なINSERT/UPDATE等は業務の操作ごとに追加設計します。DB全体のmyapp.*へのCRUDや*.*へのALLを最小権限の定型として配りません。接続確認のためのDB作成/migrateも別操作です。

同名が存在するとき、IF NOT EXISTSは更新ではない

-- A warning is not evidence that the password was changed.
CREATE USER IF NOT EXISTS 'cwiki_w23_reader'@'localhost'
  IDENTIFIED BY 'Different_public_w23_only_43!';
SHOW WARNINGS;

この検体ではMySQLが警告3163、MariaDBが1973を返しました。元のパスワードで接続でき、新しく指定した別パスワードでは1045になりました。既存アカウントのパスワードを更新した意味ではありません。警告番号/文面は版で変わる場合があります。確認せず成功扱いにせず、既存利用者の用途と実際の設定を読みます。

MariaDBのCREATE OR REPLACE USERは既存ユーザーの削除/再作成相当です。MySQL共通の安全な上書きではなく、既存権限等を失う可能性があります。このページでは実行していません。既存名があった場合の回避策にしません。パスワード変更やロック解除も既存利用者へ影響する別の承認対象です。

認証を選ぶときの製品差

IDENTIFIED BYの同じ形でも、認証pluginの選択やポリシーは製品/設定によります。検体ではMySQL8.4.13はcaching_sha2_password、MariaDB11.8.9はmysql_native_passwordになりました。MariaDBの結果をMySQLへそのまま移しません。MySQLの旧native方式は8.4で既定無効/9.0で削除です。クライアントの対応状況を確認せず認証方式を弱めないでください。

MySQLのIDENTIFIED WITHとMariaDBのIDENTIFIED VIA/WITH、複数認証やsocket認証の構文は同一ではありません。OSのrootでsocket接続できる状態を、同じDB名でパスワード接続できる証明にしません。外部認証のアカウントへローカルパスワード変更を一律適用せず、その認証元の管理手順を確認します。

秘密値を残さない運用は別に設計する

DBのパスワードを確認するためにmysql.userの全列、mysql.global_privのJSON、SHOW CREATE USERの全結果を公開する必要はありません。ハッシュも秘密情報です。CREATE USERの平文秘密値は、クライアント履歴やログ等へ残る条件があります。「DBでハッシュ化されるから一切残らない」とは言えません。実値の入力・履歴/ログ・保管・アクセス制限・更新を運用方針に合わせて設計します。

SQLの識別子と文字列は別です。DB/表の名前と、'user'@'host'、パスワード文字列を同じ連結方法で組み立てないでください。アプリの任意入力から管理SQLを作る機能はこの例には含めません。接続元制限とTLSの暗号化/接続先識別検証も別であり、作成成功だけでは通信の安全性を保証しません。

失敗したときの確認順

• 1396等の作成失敗：対象host込みの既存アカウントと操作権限を管理者が確認します。DROPして作り直す前提にしません。
• 1045の接続失敗：実際の接続先/経路/照合候補/認証方式を確認します。using password: YESは正しいパスワードという意味ではありません。
• 接続後の1142/1044：失敗した操作と対象表/DBを確認します。接続エラーと混同せず、必要な権限の範囲を限定します。
• 既存poolだけ挙動が違う：権限変更の反映条件と再接続を確認します。サーバーや全サービスの再起動を自動的な解決策にしません。

次はユーザー一覧で同名/別hostと権限を確認し、名前を変える必要がある場合だけRENAME USERへ進みます。元のSQLとGRANTでの作成例は、製品/版の条件が異なる保守資料として注意付きで残しています。

元のMariaDB SQLを保守資料として残す

MariaDBのユーザー新規作成SQLです。

元SQLの構文（旧記録）：日本語は置換箇所です。GRANTでの作成と認証指定を組み合わせた旧方式で、MySQL8.4の作成構文ではありません。MariaDBでも版/sql_mode等の条件があります。新しい例ではCREATE USERとGRANTを分けています。

【構文】

GRANT 権限 
ON データベース名.テーブル名 
TO ユーザ名@接続元ホスト(クライアント側)
IDENTIFIED BY パスワード

元SQLの例（実行しない）：ALLは読取だけの最小権限ではなく、公開値XXXXを実パスワードに使いません。testDbやtestUserは例です。既存DBにこの例を実行せず、「隔離検体の作成例」を参照してください。

【例】

GRANT ALL PRIVILEGES 
ON testDb.* 
TO testUser@localhost 
IDENTIFIED BY 'XXXX';
 

Linuxのユーザー作成とは別の記事です

全11履歴と実親を確認し、元v1〜6のDBユーザー作成へ用途を修復しました。誤って置き換わったLinux本文はv11の履歴を含めて保存しています。OSのユーザー作成を調べる場合は、既存のLinux配下のuseradd、usermod、userdelを参照できます。今回はLinux記事の移動/新設やOSアカウント操作をしていません。既存Linux記事の全手順を今回再検証したという意味ではありません。

確認範囲と関連ページ

2026年10月26日確認。掲載した新8SQLをローカルの新規tmpfs MySQL8.4.13/MariaDB11.8.9-ubu2404で実行し、各12/計24試験に成功しました。作成だけの表読取拒否、SELECT許可と書込拒否、IF NOT EXISTS後の旧/別パスワード、別hostの保持、RENAMEの接続/権限/衝突/複数指定/DEFINER viewの差を検査しました。本番アカウント/認証/権限/DB設定には変更していません。全製品/旧版/全認証pluginやTLS実通信、replication、既存pool、全DEFINERオブジェクト、旧比較の全SQLを実行保証するものではありません。新図は900/360pxの静止画で文字枠を確認し、実ブラウザ/実端末の検証とは区別しています。

ユーザー関連の親ページから子ページを選択できます。作成、名前変更、一覧、製品配下のSQL、MySQL/MariaDBも参照してください。

一次資料：MySQL CREATE USERと既存名・秘密情報、MariaDB CREATE USERとhost、MySQL RENAME USERとDEFINER保護、MariaDB RENAME USERの部分成功、権限変更の反映、MySQLアカウント名とhost、MariaDB mysql.userの互換view、MySQL SHOW GRANTSとロール、MariaDB SHOW GRANTS、MySQL旧native認証の廃止、PostgreSQL psqlのロール一覧、PostgreSQLロール、Oracle DBA_USERS。