Làm cách nào để quản lý QUYỀN RIÊNG TƯ CHO NGƯỜI DÙNG trên cơ sở dữ liệu so với SCHema?

Tôi muốn di chuyển một ứng dụng điều khiển cơ sở dữ liệu khá đơn giản, nội bộ, từ SQLite3 sang PostgreQuery 9.3 và thắt chặt các quyền trong DB khi tôi đi.

Ứng dụng hiện bao gồm một lệnh để cập nhật dữ liệu; và một để truy vấn nó. Đương nhiên, tôi cũng cần duy trì cơ sở dữ liệu theo những cách khác (tạo bảng mới, dạng xem, trình kích hoạt, v.v.).

Mặc dù ứng dụng này sẽ là ứng dụng duy nhất được lưu trữ trên máy chủ lúc đầu, tôi muốn sử dụng giả định rằng nó có thể được lưu trữ trên máy chủ với các cơ sở dữ liệu khác trong tương lai, thay vì phải tranh giành sau này nếu điều đó trở nên cần thiết trong tương lai.

Tôi nghĩ rằng đây sẽ là một tập hợp các yêu cầu khá phổ biến, nhưng tôi gặp khó khăn khi tìm một hướng dẫn đơn giản giải thích cách thiết lập cơ sở dữ liệu mới trong PostgreQuery, với loại phân tách người dùng / đặc quyền này. Các tài liệu tham khảo tiếp tục về các nhóm, người dùng, vai trò, cơ sở dữ liệu, lược đồ và tên miền; nhưng tôi thấy chúng khó hiểu

Đây là những gì tôi đã thử cho đến nay (từ bên trong psqllà 'postgres'):

CREATE DATABASE hostdb;
REVOKE ALL ON DATABASE hostdb FROM public;
\connect hostdb
CREATE SCHEMA hostdb;
CREATE USER hostdb_admin WITH PASSWORD 'youwish';
CREATE USER hostdb_mgr   WITH PASSWORD 'youwish2';
CREATE USER hostdb_usr WITH PASSWORD 'youwish3';

GRANT ALL PRIVILEGES ON DATABASE hostdb TO hostdb_admin;
GRANT CONNECT ON DATABASE hostdb TO hostdb_mgr, hostdb_usr;
ALTER DEFAULT PRIVILEGES IN SCHEMA hostdb GRANT SELECT, INSERT, UPDATE, DELETE ON TABLES TO hostdb_mgr;
ALTER DEFAULT PRIVILEGES IN SCHEMA hostdb GRANT SELECT ON TABLES TO hostdb_usr;

Nhưng tôi không nhận được ngữ nghĩa dự định. Tôi muốn cấu hình nó để chỉ các bảng hostdb_admincó thể tạo (và thả và thay đổi); các hostdb_mgrthể đọc, chèn, cập nhật và xóa trên tất cả các bảng theo mặc định; và hostdb_usrchỉ có thể đọc tất cả các bảng (và khung nhìn).

Khi tôi thử điều này, tôi thấy rằng tôi có thể tạo các bảng trong hostdbbất kỳ người dùng nào trong số này; nhưng, đối với mỗi người dùng, tôi chỉ có thể đọc hoặc sửa đổi các bảng được tạo bởi người dùng đó - trừ khi tôi sử dụng một bảng tường minh GRANT.

Tôi đoán rằng có một cái gì đó bị thiếu giữa CREATE DATABASEvà CREATE SCHEMA, một cái gì đó để áp dụng SCHEMAcho DATABASE?

(Khi mọi thứ trở nên nâng cao hơn, tôi cũng sẽ có câu hỏi để áp dụng các hạn chế tương tự đối với TRIGGERS, các thủ tục được lưu trữ VIEWSvà có lẽ các đối tượng khác).

Tôi có thể tìm thấy một hướng dẫn phong phú, hướng dẫn hoặc loạt video về điều này?

Tôi có thể tìm thấy một hướng dẫn phong phú, hướng dẫn hoặc loạt video về điều này?

Bạn sẽ tìm thấy mọi thứ trong hướng dẫn. Liên kết dưới đây.
Cấp, vấn đề không tầm thường và đôi khi khó hiểu. Đây là một công thức cho trường hợp sử dụng:

Công thức

Tôi muốn cấu hình nó để chỉ các bảng hostdb_admincó thể tạo (và thả và thay đổi);
các hostdb_mgrthể đọc, chèn, cập nhật và xóa trên tất cả các bảng theo mặc định;
và hostdb_usrchỉ có thể đọc tất cả các bảng (và khung nhìn).

Là siêu người dùng postgres:

CREATE USER schma_admin WITH PASSWORD 'youwish';
-- CREATE USER schma_admin WITH PASSWORD 'youwish' CREATEDB CREATEROLE; -- see below
CREATE USER schma_mgr   WITH PASSWORD 'youwish2';
CREATE USER schma_usr   WITH PASSWORD 'youwish3';

Nếu bạn muốn có một quản trị mạnh mẽ hơn mà còn có thể quản lý cơ sở dữ liệu và vai trò, thêm thuộc tính vai trò CREATEDBvàCREATEROLE ở trên.

Cấp mỗi vai trò cho cấp cao hơn tiếp theo, vì vậy tất cả các cấp "kế thừa" ít nhất là tập hợp các đặc quyền từ cấp thấp hơn tiếp theo (xếp tầng):

GRANT schma_usr TO schma_mgr;
GRANT schma_mgr TO schma_admin;

CREATE DATABASE hostdb;
REVOKE ALL ON DATABASE hostdb FROM public;  -- see notes below!

GRANT CONNECT ON DATABASE hostdb TO schma_usr;  -- others inherit

\connect hostdb  -- psql syntax

Tôi đang đặt tên cho lược đồ schma(không hostdbgây nhầm lẫn). Chọn bất kỳ tên nào. Tùy chọn làm schma_adminchủ sở hữu của lược đồ:

CREATE SCHEMA schma AUTHORIZATION schma_admin;

SET search_path = schma;  -- see notes

ALTER ROLE schma_admin IN DATABASE hostdb SET search_path = schma; -- not inherited
ALTER ROLE schma_mgr   IN DATABASE hostdb SET search_path = schma;
ALTER ROLE schma_usr   IN DATABASE hostdb SET search_path = schma;

GRANT USAGE  ON SCHEMA schma TO schma_usr;
GRANT CREATE ON SCHEMA schma TO schma_admin;

ALTER DEFAULT PRIVILEGES FOR ROLE schma_admin
GRANT SELECT                           ON TABLES TO schma_usr;  -- only read

ALTER DEFAULT PRIVILEGES FOR ROLE schma_admin
GRANT INSERT, UPDATE, DELETE, TRUNCATE ON TABLES TO schma_mgr;  -- + write, TRUNCATE optional

ALTER DEFAULT PRIVILEGES FOR ROLE schma_admin
GRANT USAGE, SELECT, UPDATE ON SEQUENCES TO schma_mgr;  -- SELECT, UPDATE are optional 

Để and drop and alterxem ghi chú dưới đây.

Khi mọi thứ trở nên tiên tiến hơn, tôi cũng sẽ có câu hỏi để áp dụng các hạn chế tương tự đối với TRIGGERS, các thủ tục được lưu trữ VIEWSvà có lẽ các đối tượng khác.

Lượt xem là đặc biệt. Cho một:

... (nhưng lưu ý rằng ALL TABLESđược coi là bao gồm các khung nhìn và các bảng nước ngoài).

Và để xem cập nhật :

Lưu ý rằng người dùng thực hiện thao tác chèn, cập nhật hoặc xóa trên chế độ xem phải có đặc quyền chèn, cập nhật hoặc xóa tương ứng trên chế độ xem. Ngoài ra, chủ sở hữu của chế độ xem phải có các đặc quyền có liên quan trên các quan hệ cơ sở cơ bản, nhưng người dùng thực hiện cập nhật không cần bất kỳ quyền nào đối với các quan hệ cơ sở cơ bản (xem Mục 38.5 ).

Triggers là đặc biệt, quá. Bạn cần TRIGGERđặc quyền trên bàn và:

• Các đặc quyền cần thiết để thực thi chức năng kích hoạt trong PostgreSQL 8.4 là gì?

Nhưng chúng tôi đã mở rộng quá mức phạm vi của câu hỏi này ...

Ghi chú quan trọng

Quyền sở hữu

Nếu bạn muốn cho phép schma_admin(một mình) thả và thay đổi bảng, hãy tạo vai trò sở hữu tất cả các đối tượng. Tài liệu:

Quyền bỏ một đối tượng, hoặc thay đổi định nghĩa của nó theo bất kỳ cách nào, không được coi là một đặc quyền có thể cấp; nó là vốn có của chủ sở hữu, và không thể được cấp hoặc thu hồi. (Tuy nhiên, hiệu ứng tương tự có thể đạt được bằng cách cấp hoặc thu hồi tư cách thành viên trong vai trò sở hữu đối tượng; xem bên dưới.) Chủ sở hữu cũng có tất cả các tùy chọn cấp cho đối tượng.

ALTER TABLE some_tbl OWNER TO schma_admin;

Hoặc tạo tất cả các đối tượng có vai tròschma_adminbắt đầu, sau đó bạn không cần thiết lập chủ sở hữu một cách rõ ràng. Nó cũng đơn giản hóa các đặc quyền mặc định, mà sau đó bạn chỉ phải đặt cho một vai trò:

Các đối tượng tồn tại từ trước

Các đặc quyền mặc định chỉ áp dụng cho các đối tượng mới được tạo và chỉ cho vai trò cụ thể mà chúng được tạo. Bạn cũng sẽ muốn điều chỉnh quyền cho các đối tượng hiện có :

• Quyền bị từ chối cho quan hệ <bảng>

Điều tương tự cũng áp dụng nếu bạn tạo các đối tượng có vai trò chưa được DEFAULT PRIVILEGESđặt, như siêu người dùng postgres. Quyền sở hữu phân công lại đến schma_adminvà đặc quyền thiết lập bằng tay - hoặc bộ DEFAULT PRIVILEGEScho postgreslà tốt (trong khi kết nối với DB đúng!):

ALTER DEFAULT PRIVILEGES FOR ROLE postgres GRANT ...  -- etc.

Đặc quyền mặc định

Bạn đã thiếu một khía cạnh quan trọng của ALTER DEFAULT PRIVILEGESlệnh. Nó áp dụng cho vai trò hiện tại trừ khi có quy định khác:

• Không thể thay đổi đặc quyền mặc định

Đặc quyền mặc định chỉ áp dụng cho cơ sở dữ liệu hiện tại. Vì vậy, bạn không gây rối với các cơ sở dữ liệu khác trong cụm DB. Tài liệu:

cho tất cả các đối tượng được tạo trong cơ sở dữ liệu hiện tại

Bạn cũng có thể muốn đặt các đặc quyền mặc định cho FUNCTIONSvà TYPES(không chỉ TABLESvà SEQUENCES), nhưng những đặc quyền đó có thể không cần thiết.

Đặc quyền mặc định cho PUBLIC

Các đặc quyền mặc định được cấp PUBLIClà thô sơ và được đánh giá quá cao bởi một số người. Tài liệu:

PostgreSQL cấp các đặc quyền mặc định cho một số loại đối tượng PUBLIC. Không có đặc quyền nào được cấp PUBLICtheo mặc định trên các bảng, cột, lược đồ hoặc không gian bảng. Đối với các loại khác, các đặc quyền mặc định được cấp PUBLICnhư sau: CONNECTvà CREATE TEMP TABLEcho cơ sở dữ liệu; EXECUTEđặc quyền cho các chức năng; và USAGE đặc quyền cho các ngôn ngữ.

Nhấn mạnh đậm của tôi. thông thường, một lệnh ở trên là đủ để bao gồm mọi thứ:

REVOKE ALL ON DATABASE hostdb FROM public;

Đặc biệt, không có đặc quyền mặc định nào được cấp PUBLICcho các lược đồ mới. Có thể nhầm lẫn rằng lược đồ mặc định có tên "công khai" bắt đầu bằng các ALLđặc quyền cho PUBLIC. Đó chỉ là một tính năng tiện lợi để dễ dàng bắt đầu với cơ sở dữ liệu mới được tạo. Nó không ảnh hưởng đến các lược đồ khác theo bất kỳ cách nào. Bạn có thể thu hồi các đặc quyền này trong cơ sở dữ liệu mẫu template1, sau đó tất cả các cơ sở dữ liệu mới được tạo trong cụm này bắt đầu mà không có chúng:

\connect template1
REVOKE ALL ON SCHEMA public FROM public;

Đặc quyền TEMP

Vì chúng tôi đã thu hồi tất cả các đặc quyền hostdbtừ PUBLIC, người dùng thông thường không thể tạo các bảng tạm thời trừ khi chúng tôi cho phép rõ ràng. Bạn có thể hoặc không muốn thêm điều này:

GRANT TEMP ON DATABASE hostdb TO schma_mgr;

search_path

Đừng quên thiết lập search_path. Nếu bạn chỉ có một cơ sở dữ liệu trong cụm, bạn có thể đặt mặc định toàn cục vào postgresql.conf. Khác (nhiều khả năng) đặt nó làm tài sản của cơ sở dữ liệu, hoặc chỉ cho các vai trò liên quan hoặc thậm chí là sự kết hợp của cả hai. Chi tiết:

• Làm thế nào để tìm kiếm ảnh hưởng đến độ phân giải định danh và lược đồ hiện tại

Bạn có thể muốn đặt nó thành schma, publicnếu bạn cũng sử dụng lược đồ công khai hoặc thậm chí (ít khả năng hơn) $user, schma, public...

Một cách khác là sử dụng lược đồ mặc định "công khai" sẽ hoạt động với các cài đặt mặc định search_pathtrừ khi bạn thay đổi. Hãy nhớ thu hồi các đặc quyền PUBLICtrong trường hợp này.

Liên quan

• Cấp đặc quyền cho một cơ sở dữ liệu cụ thể trong PostgreSQL
• PostgreSQL - Người dùng DB chỉ được phép gọi các chức năng