Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
PostgreSQLのロール・権限のここがわかりづらい
Search
Sponsored
·
Your Podcast. Everywhere. Effortlessly.
Share. Educate. Inspire. Entertain. You do you. We'll handle the rest.
→
まぐろ
July 03, 2023
Programming
2
2.4k
PostgreSQLのロール・権限のここがわかりづらい
まぐろ
July 03, 2023
Tweet
Share
More Decks by まぐろ
See All by まぐろ
PL/pgSQLの基本と使い所
tameguro
2
460
PostgreSQLで手続き言語を動かす PL/pgSQL入門
tameguro
0
960
Other Decks in Programming
See All in Programming
MUSUBIXとは
nahisaho
0
140
SourceGeneratorのススメ
htkym
0
200
登壇資料を作る時に意識していること #登壇資料_findy
konifar
4
1.7k
ぼくの開発環境2026
yuzneri
0
240
OSSとなったswift-buildで Xcodeのビルドを差し替えられるため 自分でXcodeを直せる時代になっている ダイアモンド問題編
yimajo
3
630
AI時代のキャリアプラン「技術の引力」からの脱出と「問い」へのいざない / tech-gravity
minodriven
21
7.4k
「ブロックテーマでは再現できない」は本当か?
inc2734
0
1k
コマンドとリード間の連携に対する脅威分析フレームワーク
pandayumi
1
460
[KNOTS 2026登壇資料]AIで拡張‧交差する プロダクト開発のプロセス および携わるメンバーの役割
hisatake
0
300
AI & Enginnering
codelynx
0
120
AIによる開発の民主化を支える コンテキスト管理のこれまでとこれから
mulyu
3
470
dchart: charts from deck markup
ajstarks
3
1k
Featured
See All Featured
How to build an LLM SEO readiness audit: a practical framework
nmsamuel
1
650
Navigating Team Friction
lara
192
16k
The Art of Programming - Codeland 2020
erikaheidi
57
14k
Jamie Indigo - Trashchat’s Guide to Black Boxes: Technical SEO Tactics for LLMs
techseoconnect
PRO
0
65
Intergalactic Javascript Robots from Outer Space
tanoku
273
27k
The AI Search Optimization Roadmap by Aleyda Solis
aleyda
1
5.2k
HDC tutorial
michielstock
1
390
Ethics towards AI in product and experience design
skipperchong
2
200
Done Done
chrislema
186
16k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
21
1.4k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
37
6.3k
Google's AI Overviews - The New Search
badams
0
910
Transcript
PostgreSQLのロール・権限 のここがわかりづらい! まぐろ
はじめに • 虎の巻でわいわい言っていた皆さんお疲れさまでした、16でも ロール周りは複雑になりそうです • そもそも、PostgreSQLのロールや権限周りの設定・機能って わかりにくいですよね? わたしも全然わかりません • というわけで、とにかく個人的に「ここがわかりづらい!」と
いう点を列挙しました • 残念ながら「こうすればわかりやすくなるよ!」という話はあ りません
自己紹介 • まぐろ(Twitter:@tameguro) • 都内某SI勤務のSE • PostgreSQLの設計・導入・保守などをやっていたこともあります • PostgreSQL歴はだいたい10年くらい •
PostgreSQLの技術同人誌をいくつか書いてます • その縁で電子書籍として商業誌を書かせてもらえました • Kindleなどで「目黒聖」で検索するとたぶんなんか出てきます
ロールの属性
まずは基本のおさらいから… • PostgreSQLではユーザもグループもいわゆるロールもひっく るめて、すべて「ロール」として扱われます • 端的に言うと、ログイン属性を持つロールをユーザ、ログイン 属性を持たないロールをグループとして扱います • CREATE ROLEでロールを作成しますが、次のSQLも有効です
• CREATE USER:ログイン属性をデフォルトで付加してロールを作成 • CREATE GROUP:単にCREATE ROLEの別名
ロールの属性とは? • スーパーユーザ、データベース作成、ロールの作成、ログイン、 レプリケーションなど、データベース全体にまたがる役割です • Oracleでいう「システム権限」に近い……かもしれない…… • 「属性」とは言いますが「権限」と言っても差し支えなく、日 常会話では「権限」と言っても全く問題ありません •
実質権限ではありますが、GRANTやREVOKEではなくALTERで 変更します • つまりPostgreSQLには権限の設定の方法が2つある
グループについて
ロールとグループについて • CREATE GROUPはCREATE ROLEの別名となっており、 PostgreSQLにおいて実質的にグループはなくなっていると 思っていいでしょう • 下位互換のためpg_groupシステムビューは残っていますが、結局は pg_rolesシステムビューのrolcanloginがfalseのロールを表示している
のみ • グループは存在せず、ユーザとロール(いくつかの権限を集め た権限の集合)しかないと考えたほうがいいと思います
グループと考えてしまうと… • グループだとこのGRANT文が理解しにくくなります • 普通はグループの中にユーザなのに、GRANT文ではユーザの中にグルー プを入れているように見えてしまい、どっちがグループかわかりにくい • ロール(権限の集合)と考えればGRANT文は妥当に見えます
グループなんてものは存在しない • グループという概念は忘れたほうがよさそうです • いつまでも下位互換と言わず整理して廃止したら? こういうところに残ってる (英語ではMember of)
オブジェクト権限 も曲者
オブジェクト権限は複雑すぎる • saitamaユーザとtokyoユーザがいて、それぞれsaitamaスキー マとtokyoスキーマの所有者であり、他の権限は何もついてい ない状態とします • Oracleはユーザとスキーマが一緒ですが、それを擬似的に再現 していると思ってください
オブジェクト権限は複雑すぎる • tokyoスキーマにはtestというテーブルがありますが… • saitamaユーザが検索すると、tokyoスキーマへのアクセス権限 がないと言われてしまいます
オブジェクト権限は複雑すぎる • それでは、saitamaユーザにtokyoスキーマの全権限を与えてみます • もう一度saitamaユーザで検索すると… • tokyoスキーマの全権限を与えたはずなのに、tokyoスキーマに存在 するテーブルが参照できません
オブジェクト権限について • PostgreSQLでは、オブジェクトごとにどんな権限が設定できるかが 決まっており、スキーマはUSAGEとCREATE権限のみを与えること ができます • USAGEはオブジェクトによって意味が異なるが、スキーマではスキーマ内の オブジェクト名を参照できる権限 • つまり、GRANT
ALL ON SCHEMAを実行しても、「そのスキーマ にあるオブジェクト名を参照する権限」と、「そのスキーマにオブ ジェクトを作成する権限」が与えられるだけで、そのスキーマとそ の中のオブジェクトに対してなんでもできちゃう権限が与えられる わけではない • もちろんテーブルを参照するにはスキーマの権限がないとダメなの で、誰にどのオブジェクトに対しどういう権限を与えるかをミスる と予想外の動きをする
None
テーブルの全権限を与えるには • ちょっと工夫が必要です • テーブルが参照できるようになりました!
新規テーブルの権限 • しかし新しくテーブルを作ると… • 新しいテーブルは検索できません
デフォルト権限
デフォルト権限というものがあります! • GRANTやREVOKEは「すでに存在しているオブジェクトに対し て」権限を付与したり剥奪したりする構文 • まだ存在していないオブジェクトに対しては、デフォルト権限 というものが存在します! • その名の通り、「新しく作成されたオブジェクトに対して」デ フォルトの権限を割り当てるというもの
• 動的にテーブルが増えたり開発中でテーブル設計が変わる可能 性が高いときに使ったりします
デフォルト権限というものがあります! • ALTER DEFAULT PRIVILEGES構文(詳しくはマニュアルを参 照) • 「今後tokyoスキーマに作成されるテーブルに対し、saitama ロールに自動的にSELECT権限を付与する」という意味 •
めんどくさいしいくらなんでもわかりにくすぎる ALTER DEFAULT PRIVILEGES IN SCHEMA tokyo GRANT SELECT ON TABLES TO saitama;
今ついてる権限は?
権限を確認するには • オブジェクト権限はpg_catalog.pg_classのrelaclという列に保存さ れています • アルファベット1文字が権限を表します • が、例えば「a=append(INSERT)」などマニュアルを見ないとわか らない表し方になっており、パッと見どういう権限なのか全然わか りません
権限を付与されたロール=付与された権限/権限を付与したロール
None
権限を確認するには • オブジェクトについている権限しかわからない • でも一般的に権限って、「誰が」「どういう」権限を持ってい るか?or持っていないか?で確認したくないですか? • ユーザがどういう権限を持っているかを一発で出すコマンドは ない(はず) •
オブジェクトからユーザの持ってる権限を探すって結構きつい し、漏れも出てきそう
デフォルト権限を確認するには • デフォルト権限はpg_default_aclカタログに記録されています • ¥ddpメタコマンドで確認できます
まとめ • 属性と権限の設定方法統一してほしい… • 現在サポート中のバージョンではすでにグループという概念が ないのだから、すべて廃止すればいいのでは? • オブジェクト権限を真面目に設定するの難しすぎる • デフォルト権限がわかりにくい
• ユーザが付与されている権限を確認 できる方法がほしい • 権限分掌はわかるんですけどより複雑で 直感的じゃない方に進んでないですかね?