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
まぐろ
July 03, 2023
Programming
1
710
PostgreSQLのロール・権限のここがわかりづらい
まぐろ
July 03, 2023
Tweet
Share
Other Decks in Programming
See All in Programming
Enjoy Creative Coding with Ruby (RubyKaigi2024)
chobishiba
0
770
Exploring the Implementation of “t.Run”, “t.Parallel”, and “t.Cleanup”
akarin
1
160
Try creating your own orderedmap
kazamori
1
290
Ruby on Fails - effective error handling with Rails conventions
talyssonoc
0
300
Open standards for building event-driven applications in the cloud
meteatamel
0
230
Timeline エディター拡張入門
yucchiy
0
450
Namespace, What and Why
tagomoris
3
700
Go製Webアプリケーションのエラーとの向き合い方大全、あるいはやっぱりスタックトレース欲しいやん / Kyoto.go #50
utgwkk
6
2k
“Seeing Like a Programmer”—Resiliency, Limits, and Moral Hazards in Software Engineering (LambdaConf 2024)
chriskrycho
0
430
WinActorの勉強を継続する方法
tamai_63
0
130
The Cutting Edge Of Versioning (LambdaConf 2024)
chriskrycho
0
250
ServerAction で Progressive Enhancement はどこまで頑張れるか? / progressive-enhancement-with-server-action
takefumiyoshii
6
520
Featured
See All Featured
Documentation Writing (for coders)
carmenintech
60
4k
Designing Experiences People Love
moore
136
23k
Why Our Code Smells
bkeepers
PRO
331
56k
Statistics for Hackers
jakevdp
790
220k
Intergalactic Javascript Robots from Outer Space
tanoku
266
26k
Debugging Ruby Performance
tmm1
70
11k
Building Better People: How to give real-time feedback that sticks.
wjessup
356
18k
Rebuilding a faster, lazier Slack
samanthasiow
74
8.3k
The Pragmatic Product Professional
lauravandoore
26
5.9k
Designing for Performance
lara
601
67k
Unsuck your backbone
ammeep
664
57k
Building an army of robots
kneath
300
41k
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メタコマンドで確認できます
まとめ • 属性と権限の設定方法統一してほしい… • 現在サポート中のバージョンではすでにグループという概念が ないのだから、すべて廃止すればいいのでは? • オブジェクト権限を真面目に設定するの難しすぎる • デフォルト権限がわかりにくい
• ユーザが付与されている権限を確認 できる方法がほしい • 権限分掌はわかるんですけどより複雑で 直感的じゃない方に進んでないですかね?