您好,登錄后才能下訂單哦!
這篇文章主要為大家展示了“PostgreSQL數據庫中如何應對登錄的用戶分配賬戶和權限”,內容簡而易懂,條理清晰,希望能夠幫助大家解決疑惑,下面讓小編帶領大家一起研究并學習一下“PostgreSQL數據庫中如何應對登錄的用戶分配賬戶和權限”這篇文章吧。
針對這個測評項,首先我們要搞清楚postgresql數據庫的相應權限問題
在postgresqll數據庫中,認為用戶就是一個相應的role,PostgreSQL使用角色的概念管理數據庫訪問權限。一個角色可以被看成是一個數據庫用戶或者是一個數據庫用戶組,這取決于角色被怎樣設置。角色可以擁有數據庫對象(例如,表和函數)并且能夠把那些對象上的權限賦予給其他角色來控制誰能訪問哪些對象。此外,還可以把一個角色中的成員資格授予給另一個角色,這樣允許成員角色使用被賦予給另一個角色的權限。
1.1 role屬性
可以認為是這個用戶所具有的系統權限.
LOGIN --具有登錄權限
SUPERUSER --超級用戶,具有所有系統權限,除了登錄驗證
CREATEDB --創建數據庫權限
CREATEROLE --創建role權限
PASSWORD --設置密碼
1.2 修改屬性
創建test角色
create role test login;
alter role test createdb createrole password '****@123';
alter role test nocreatedb nocreaterole superuser;
通過psql程序登錄可使用\du命令列出現有角色,以及相應的角色權限
role membership(role成員)為了管理上的方便,我們可以創建一個role group,然后可以將各用戶或者有特殊權限的role組織在一起,各個role就是這個role group的membership.
role group 是不帶login的role,因為pg使用role來表示所有的角色、用戶、用戶組,所以不要混淆,創建語句都是create role.
2.1 繼承role group
1)直接繼承
我們創建一個用戶,兩個角色,分別有直屬一個表的查詢權限create role jack login inherit;create role r1;create role r2;
然后創建對應的表
授予查詢權限
進行grant授權,使jack成為r1,r2的membership
測試角色切換
jack 繼承了r1,r2的權限
2)間接繼承
移除membership
可以使用revoke group_role from role1,…命令
此時,r1屬于r2,然后jack又屬于r1
關閉r1的繼承
alter role r1 noinherit;
然后再嘗試訪問tab,發現tab2無法訪問取消繼承權限后,r1也無權限訪問
移除后將無權限
注意:授權不能形成回路
3)系統權限任何時候都不會主動繼承
系統權限不會繼承,只有主動set才生效
使用set命令后,該會話會具有group_role的臨時系統權限,且會被認為是group_role角色,創建的表之類的均為set role的權限
重新開啟會話后,無權限
三種方式還原到最初的jack角色:
綜上所述:角色屬性login、superuser、createdb和createrole可以被認為是一種特殊權限,但是它們從來不會像數據庫對象上的普通權限那樣被繼承。要使用這些屬性,你必須實際set role到一個有這些屬性之一的特定角色。
4)角色刪除
刪除role,role下有權限或者是對象屬于此role,則刪除不了
移除掉相關權限關聯后進行刪除,然后涉及到r1的成員或者是group_role自動釋放
pg中的role包含了用戶,角色,角色組,成員等所有含義,如使用create role來創建
一個role可以成為多個role的成員,根據role的inherit屬性來決定是否集成其他role的各種權限
繼承關系不能形成回路
刪除role需要先清理此role關聯的各種權限
查看當前數據庫內有哪些角色,可通過工具進行查看
然后再查看對應角色對應的權限
命令行界面可以通過\du命令列出現有角色和權限
個人認為,針對第一個條款,不管權限分配是否合理,只要給用戶分配權限了就算符合
這條條款主要是為了防止匿名用戶的登錄,像NTP匿名登錄那種
至于權限是否合理,已在后面的最小權限,管理用戶的權限分離,訪問控制粒度的地方體現,應在那些條款內去判斷,所以對于第一條我們只要看他是否為用戶分配了相應的賬戶和權限即可。
可以通過工具進行查看
PostgreSQL提供一組默認角色, 他們可以訪問特定的、通常需要的特權功能和信息。 管理員可以將這些角色 GRANT 給用戶和/或其環境中的其他角色, 為這些用戶提供對指定功能和信息的訪問權限。請注意,每個默認角色的特定權限可能會因為將來添加額外的功能而發生變化。 管理員應監控發行說明以進行更改,如下圖:
角色 | 允許的權限 |
pg_read_all_settings | 閱讀所有配置變量,即使那些通常只對超級用戶可見的配置變量。 |
pg_read_all_stats | 閱讀所有pg_stat_*視圖并使用各種統計相關的擴展,甚至那些通常只對超級用戶可見的擴展。 |
pg_stat_scan_tables | 執行可能對表進行可能需要很長時間ACCESS SHARE鎖定的監視功能。 |
pg_signal_backend | 給其他后端發送信號(比如: 取消查詢、終止)。 |
pg_monitor | 讀取/執行各種監視視圖和函數。 此角色是pg_read_all_settings、 pg_read_all_stats和 pg_stat_scan_tables的成員。 |
pg_mointor、pg_read_all_settings、pg_read_all_stats和pg_scan_tables角色旨在允許管理員輕松配置角色以見識數據庫服務器。他們授予一組通用權限,允許角色讀取通常僅限于超級用戶的各種有用的配置設置,統計和其他系統信息。應小心授予這些角色,以確保只在需要執行所需監視的情況下才會使用這些角色。管理員可以使用grant命令給這些用戶授予訪問權限:grant pg_signal_backend to admin_user;上述的的默認角色默認都是不可登錄的。
默認賬戶為postgres,查看其是否設置禁止登錄,或將其重命名在psql的程序下可以通過\du命令查看,無法登錄將有cannot login字樣
以上是“PostgreSQL數據庫中如何應對登錄的用戶分配賬戶和權限”這篇文章的所有內容,感謝各位的閱讀!相信大家都有了一定的了解,希望分享的內容對大家有所幫助,如果還想學習更多知識,歡迎關注億速云行業資訊頻道!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。