ユーザ

サーバのアカウントを、その権限とともに作成、編集、削除します。

場所： ワークスペース › ツール › ユーザ

ワークスペースのナビゲーションバーから「ユーザ」を開きます。左のパネルにはサーバ上のすべてのアカウントが一覧表示され、サーバがインストールしたものは別のグループにまとめられています。検索欄で名前で絞り込めます。アカウントを選ぶと、その権限が読み込まれます。

右側に何が表示されるかはエンジンによって変わります。セキュリティモデルが同じではないからです。MySQLとMariaDBでは、アカウントはuser@hostで、権限は4つの範囲（グローバル、データベース、テーブル、ルーチン）で付与されます。PostgreSQLでは、アカウントはロールで、ホストはなく、グローバルの範囲の代わりにその属性が表示されます。属性は付与するのではなく設定するものです。エンジンにないものは、グレーで描画されるのではなく、描画されません。

各カードの中では、チェックボックスが「データ」、「構造」、「ルーチン」、「管理」、「レプリケーション」に分かれています。当てはまるものにチェックを入れて「変更を保存」を押します。未保存の変更があるあいだは見出しにそう表示され、「変更を破棄」でサーバ上の状態に戻ります。

SQL Serverでは、アカウントはサーバのログインで、ホストはありません。各データベースでは、それに結びついたユーザを通じて動作し、そのユーザはCalíopeが自分で見つけます。権限は5つの範囲（グローバル（サーバ）、接続（データベース）、データベース（スキーマ）、テーブル、ルーチン）で付与され、DENYは3つ目の状態として、取り消し線付きで名前を付けて表示されます：ここでは見えますが変更できません。設定と解除はSQLエディタで行います。

アカウントを読み取る権限がない場合（MySQLとMariaDBでは、mysqlデータベースに対するSELECT）、リストには「サーバのアカウントを読み取れませんでした」と表示され、その下にサーバが挙げた理由と再試行のボタンが付き、フッターには件数が表示されません。PostgreSQLではこれは起きません：どのアカウントもロールを読み取れます。SQL Serverでは、VIEW ANY DEFINITIONがないと、エラーは出ずに表示されるアカウントが少なくなります。また「バックアップ」では、この権限がないとサーバアカウントのセクションが表示されません。

読み出し専用の環境タグがあると、このツールは提示されません。書き込みを確認する環境タグでは、変更（ユーザの作成や編集、その権限、そのロール）のたびに操作の名前を挙げて先に確認を求め、ユーザの削除では確認のタイトルにタグが入ります。

キーワード： ユーザ、ロール、権限、アクセス権、GRANT、ユーザ管理

名前とパスワードでアカウントを追加します。

場所： ユーザ › 新規ユーザ

「ユーザ」のバーで「新規ユーザ」を押します。名前、ホスト、パスワードを入力します。アカウントは権限なしで作成され、選択されたままになるので、すぐに権限を割り当てられます。

「ホスト」欄と認証方式の選択は、エンジンにある場合だけ表示されます。PostgreSQLにはどちらもありません：どこからの接続を受け付けるかはサーバのpg_hba.confが決め、パスワードをどう暗号化するかはアカウントではなくサーバの設定が決めます。ロールは、CREATE USERと同じようにLOGINとINHERIT付きで作成されるので、サインインできます。ほかの属性は、あとでそのロールのカードでチェックします。

SQL Serverにもありません：アカウントはログインで、ホストも選ぶ方式もありません。

キーワード： ユーザを作成、新規ユーザ、CREATE USER、パスワード

サーバからアカウントを削除します。

場所： ユーザ › ユーザを削除

左のパネルでアカウントを選び、見出しの「削除」を押します。確認のダイアログに、何が削除されるかが表示されます。この操作は取り消せません。

サーバがインストールしたアカウントは専用のグループに表示され、ここからは削除できません。

PostgreSQLではサーバが拒否することがありますが、それはCalíopeの不具合ではありません：オブジェクトを所有しているロールや、付与された権限を持つロールは、それらを取り除くまで削除できません。Calíopeは自分からDROP OWNED BYを実行しません。誰も削除を頼んでいないデータまで削除してしまうからです。先にその付与（「すべてのテーブル」の付与も含みます。これはデフォルト権限も残します）を取り除くか、所有しているものを別のロールに移してください。

SQL Serverでは、削除するとすべてのデータベースにあるそのアカウントのユーザが削除され、そのあとログインが削除されます。それらのユーザのどれかがスキーマを所有しているあいだは、サーバが拒否します：先にスキーマを別の人に渡してください（ALTER AUTHORIZATION）。

キーワード： ユーザを削除、DROP USER、削除、取り消し

既存のアカウントのパスワードを変更します。

場所： ユーザ › ユーザを編集

左のパネルでアカウントを選び、見出しの「編集」を押します。編集フォームが開きます。

フォームにはエンジンにあるものだけが表示されます。MySQLとMariaDBでは、パスワード、認証方式、アカウントのロック、1時間あたりのリソース制限が入ります。PostgreSQLではパスワードだけです：ロックはなく（アカウントはLOGIN属性を外すことで閉じます。これはそのロールのカードにあります）、1時間あたりの制限もありません。同時接続数と有効期限は、属性の横で編集します。

フォームは、サーバにある状態で開きます：アカウントがロックされているかどうかと、1時間あたりの制限です。制限が0なら制限なしで、0に戻すと制限が外れます。ほかの設定だけを変えたい場合は、パスワード欄を空のままにしてください。

SQL Serverでは、パスワードとロック（ALTER LOGIN … DISABLE：ログインはサインインできなくなり、権限は保たれます）が入ります。1時間あたりの制限も、アカウントごとの有効期限もありません。

キーワード： パスワードを変更、パスワード、ユーザを編集、ALTER USER、資格情報、新しいパスワード

データベース、テーブル、特定のルーチンの単位で、細かな権限を割り当てます。

場所： ユーザ › 権限ツリー

権限の範囲ごとに1枚のカードがあり、付与数のカウンタとWITH GRANT OPTIONのスイッチが付きます：

- 「ロールの属性」 — PostgreSQLだけ。権限ではなく、ALTER ROLEで書くロールの性質（LOGIN、SUPERUSER、CREATEDB…）です。同時接続数と有効期限は一番下にあります。
- グローバル — MySQLファミリーとSQL Server。サーバ全体に適用されます（例：MySQLのSUPERやPROCESS、SQL ServerのVIEW SERVER STATE）。
- 接続 — PostgreSQLとSQL Server。PostgreSQLでは、プロファイルが指すクラスタのデータベースに対する権限：CONNECT、CREATE、TEMPORARYで、アカウントがそもそも接続できるかどうかを決めます。SQL Serverでは、データベース全体に対するもの（CONNECT、CREATE TABLE…）。
- データベース — あるデータベースのすべてのオブジェクトに対するもの（PostgreSQLとSQL Serverでは、スキーマのもの）。
- テーブル — 特定の1つのテーブルに対するもの。
- ルーチン — ストアドプロシージャか関数に対するもの。

各カードの中では、チェックボックスがカテゴリごとにまとめられ、グループごとに「すべてを選択」があります。ALL PRIVILEGESは範囲全体を一度に付与するので、上に強調表示されます。

一覧にない範囲を追加するには、下のバーの「オブジェクトを追加」を使います。「変更を保存」は必要なREVOKEとGRANTの文を実行します。サーバがどれかを拒否すると、ボタンの横に詳細付きの通知が表示されます。MySQLとMariaDBでは、そのあとFLUSH PRIVILEGESを実行します。アカウントの作成、編集、削除でも同じです。

キーワード： 権限、GRANT、REVOKE、データベース、テーブル、ルーチン、細かな権限、EXECUTE、SUPER

この画面がMySQLのものと違って見える理由と、各部分の意味。

場所： ワークスペース › ツール › ユーザ

PostgreSQLには、ユーザとグループの区別がありません：あるのはロールで、ロールはその両方を兼ねます。LOGIN属性を持つロールはサインインでき、持たないロールは権限をまとめてほかに渡すために存在します。だから画面の形が変わるのであって、気まぐれではありません。

ホストはありません。アカウントは名前だけです。どこからの接続を受け付けるかはpg_hba.confが決め、それはアカウントではなくサーバのものなので、Calíopeはここに表示もせず、変更もできません。

属性は権限ではありません。SUPERUSER、CREATEDB、CREATEROLE、REPLICATION、BYPASSRLS、INHERIT、LOGINは、GRANTで付与するのではなく、ALTER ROLEで設定します。保存すると、Calíopeはそれらをすべて書き込みます：チェックを外したものはオフになります。それが画面を正直に保ちます。チェックしたものだけを書き込んだら、チェックを外してもオフにならず、次にそのアカウントを開いたときにひとりでに戻ってきてしまいます。

メンバーシップは推移的です。appがreadersのメンバーで、readersがauditorsのメンバーなら、誰も付与しなくてもappはauditorsの持つものを持ちます。「所属先」のカードは、直接のメンバーシップと継承したものを区別し、それぞれの経路を示します。継承したものはここからは外せないので、ボタンがありません：取り消すべきなのはリンクで、そのリンクは別のロールのものだからです。

PUBLICはロールではありません：全員です。リストにはアカウントの1つとして表示されます。そうしないと、全員に付与したオブジェクトが非公開に見えてしまうからです。デフォルトでは、PUBLICはデータベースに接続でき、どの関数も実行できます。

所有者は所有するものに対してすべてを持ち、それが付与として表示されることは決してありません。作ったばかりのテーブルにはカタログに権限の行がまったくありませんが、その所有者は好きなように扱えます。だから見出しには「N個のオブジェクトを所有」のバッジが付き、それらのカードはチェック済みでグレーに描画されます：付与するものも取り消すものもないからです。

「すべてのテーブルに付与」は2つの文です。MySQLでは、ON database.*は明日作られるテーブルも含みます。ここでは同じ意味ではない2つのコマンドが必要です：1つは今あるテーブルに、もう1つはこれから作られるテーブルに届きます。しかも2つ目は、Calíopeが接続しているアカウントが作るテーブルしか対象にしません。どちらもあとでスキーマのカードのチェックボックスとして戻ってくることはありません。スキーマの権限ではないからです。その横のボタンは両方を元に戻します。これは必要です：デフォルト権限が残っているあいだは、サーバはアカウントの削除を許しません。

ないもの。アカウントのロックはなく（LOGINを外します）、1時間あたりの制限もなく（同時接続数だけです）、認証方式の選択もなく（サーバが決めます）、FLUSH PRIVILEGESもありません：ここではカタログそのものが情報源で、GRANTはサーバが応答した時点ですでに効いています。

キーワード： ロール、PostgreSQL、継承、メンバーシップ、PUBLIC、所有者、属性、LOGIN、SUPERUSER、GRANT、デフォルト権限