在資料庫的開發版本中，一切正常。在同一架構的托管版本中，我收到權限錯誤。當我查看相關資源的權限時，它們似乎匹配。因此，問題是，解決此錯誤的系統方法是什么？
權限錯誤
這發生在托管版本中。
select api.register('google', '333344555');
INFO: api.register: api
INFO: api.login: api
ERROR: permission denied for table auth_ids_link_user
CONTEXT: SQL function "login" statement 1
SQL statement "select auth.login(auth_agent::core.auth_agent, auth_id)"
PL/pgSQL function register(text,text,text) line 35 at SQL statement
權限似乎匹配。
作業開發版本
(PostgreSQL v13.1)
select grantor, grantee, table_schema, table_name, privilege_type
from information_schema.role_table_grants
where table_name in (select 'auth_ids_link_user');
grantor | grantee | table_schema | table_name | privilege_type
---------- --------- -------------- -------------------- ----------------
postgres | api | core | auth_ids_link_user | INSERT
(1 row)
托管版本的權限被拒絕
(PostgreSQL v13.7)
select grantor, grantee, table_schema, table_name, privilege_type
from information_schema.role_table_grants
where grantee = 'api' and table_name in (select 'auth_ids_link_user');
grantor | grantee | table_schema | table_name | privilege_type
--------- --------- -------------- -------------------- ----------------
doadmin | api | core | auth_ids_link_user | INSERT
(1 row)
auth.login從報告的功能/路由的執行權限information_schema.routine_privileges
grantor | grantee | specific_schema | routine_schema | routine_name | privilege_type
--------- ----------- ----------------- ---------------- -------------- ----------------
auth | api | auth | auth | login | EXECUTE
根據@Bergi，鑒于auth.login使用定義者權限運行，以下是授予表上 auth 的權限：
Schema | Name | Type | Access privileges | Column privileges | Policies
-------- -------------------- ------- ------------------------- ------------------- ---------------------------------------------------------------------------------------------------
core | auth_ids_link_user | table | doadmin=arwdDxt/doadmin | user_id: | Api can do anything when current_user_id:
| | | api=a/doadmin | auth=rx/doadmin | (u): ((util.current_user_id() = user_id) AND (current_setting('role'::text) = 'webuser'::text))
| | | | | (c): ((util.current_user_id() = user_id) AND (current_setting('role'::text) = 'webuser'::text))
| | | | | to: api
| | | | | Auth can view all auth_ids to authenticate anonymous users (r):
| | | | | (u): true
| | | | | to: auth
(1 row)
回應要求：auth 只需要確定是否存在條目。api 將通過插入授權插入新記錄。
我應該如何“閱讀”錯誤訊息以有效地查明問題？回答。
最后，違規許可
-- before
grant references(user_id), select(user_id) on table core.auth_ids_link_user to auth;
-- after
grant references(user_id), select on table core.auth_ids_link_user to auth;
有趣的“陷阱”不知何故從自托管的開發版本的裂縫中溜走了。權限實際上太嚴格了。我需要擴展選擇權限以包括WHERE子句中使用的欄位，而不僅僅是聯接。
我可以確定的兩個背景關系之間唯一明顯的區別是，postgres默認情況下，開發人員會將成員身份繼承到其他角色中。我已經在托管模式中考慮了這一點，因此可能不相關。
uj5u.com熱心網友回復：
你最好使用命令列客戶端psql。
檢查函式是如何定義的以及誰擁有它：
\df auth.login如果
Security是invoker，則有效用戶是呼叫函式的人，否則是函式的所有者（在輸出中也可見）檢查有效用戶及其角色成員資格：
\du user_name檢查相關表的權限：
\z auth_ids_link_user
這應該足以找到問題的原因。
當然，托管資料庫并非真正在 PostgreSQL 上運行，而是在權限系統已被破解的分支上運行，當然總是有這樣的選擇。然后，您將受制于提供者的解釋。
轉載請註明出處，本文鏈接：https://www.uj5u.com/caozuo/511365.html
標籤：PostgreSQL
上一篇：INET值陣列的正確語法
下一篇：使用查詢結果作為另一個查詢的元素