Cấp tất cả trên một lược đồ cụ thể trong db cho một vai trò nhóm trong PostgreSQL


91

Sử dụng PostgreSQL 9.0, tôi có một vai trò nhóm được gọi là "nhân viên" và muốn cấp tất cả (hoặc một số) đặc quyền cho vai trò này trên các bảng trong một lược đồ cụ thể. Không có tác phẩm nào sau đây

GRANT ALL ON SCHEMA foo TO staff;
GRANT ALL ON DATABASE mydb TO staff;

Các thành viên của "staff" vẫn không thể CHỌN hoặc CẬP NHẬT trên các bảng riêng lẻ trong lược đồ "foo" hoặc (trong trường hợp lệnh thứ hai) cho bất kỳ bảng nào trong cơ sở dữ liệu trừ khi tôi cấp tất cả trên bảng cụ thể đó.

Tôi có thể làm gì để cuộc sống của tôi và người dùng dễ dàng hơn?

Cập nhật: Tìm ra nó với sự trợ giúp của một câu hỏi tương tự trên serverfault.com .

GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA foo TO staff;

Câu trả lời:


120

Bạn đã tìm thấy tốc ký để đặt đặc quyền cho tất cả các bảng hiện có trong lược đồ đã cho. Hướng dẫn làm rõ :

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

Tôi nhấn mạnh đậm. serialcác cột được triển khai nextval()trên một trình tự làm cột mặc định và trích dẫn hướng dẫn sử dụng :

Đối với các chuỗi, đặc quyền này cho phép sử dụng các hàm currvalnextval.

Vì vậy, nếu có serialcác cột, bạn cũng sẽ muốn cấp USAGE(hoặc ALL PRIVILEGES) cho các chuỗi

GRANT USAGE ON ALL SEQUENCES IN SCHEMA foo TO mygrp;

Lưu ý: các cột nhận dạng trong Postgres 10 trở lên sử dụng chuỗi ngầm định không yêu cầu đặc quyền bổ sung. (Xem xét nâng cấp serialcác cột.)

Còn đối tượng mới thì sao?

Bạn cũng sẽ quan tâm đến DEFAULT PRIVILEGESngười dùng hoặc lược đồ :

ALTER DEFAULT PRIVILEGES IN SCHEMA foo GRANT ALL PRIVILEGES ON TABLES TO staff;
ALTER DEFAULT PRIVILEGES IN SCHEMA foo GRANT USAGE          ON SEQUENCES TO staff;
ALTER DEFAULT PRIVILEGES IN SCHEMA foo REVOKE ...;

Điều này đặt đặc quyền cho các đối tượng được tạo trong tương lai một cách tự động - nhưng không phải cho các đối tượng đã có từ trước.

Các đặc quyền mặc định chỉ được áp dụng cho các đối tượng được tạo bởi người dùng được nhắm mục tiêu ( FOR ROLE my_creating_role). Nếu mệnh đề đó bị bỏ qua, nó sẽ được mặc định cho người dùng hiện tại thực thi ALTER DEFAULT PRIVILEGES. Nói rõ ràng:

ALTER DEFAULT PRIVILEGES FOR ROLE my_creating_role IN SCHEMA foo GRANT ...;
ALTER DEFAULT PRIVILEGES FOR ROLE my_creating_role IN SCHEMA foo REVOKE ...;

Cũng lưu ý rằng tất cả các phiên bản của pgAdmin III đều có một lỗi nhỏ và hiển thị các đặc quyền mặc định trong ngăn SQL, ngay cả khi chúng không áp dụng cho vai trò hiện tại. Đảm bảo điều chỉnh FOR ROLEmệnh đề theo cách thủ công khi sao chép tập lệnh SQL.


2
chỉ để bạn biết Erwin, 10 phút sau khi bạn đăng lời khuyên của mình, tôi cần nó. Giống như bạn biết tôi sẽ làm gì ... tạo một bảng mới và thấy nó không có priv phù hợp. Câu trả lời của bạn đã đến giải cứu.
punkish

5
@punkish: Tôi yêu cầu huy hiệu precog của mình! Chết tiệt, nó đã được sử dụng cho việc khác.
Erwin Brandstetter

Khi chạy ALTER DEFAULT PRIVILEGES IN SCHEMA foo GRANT ALL PRIVILEGES ON TABLES TO staff;làm sao nó biết được cơ sở dữ liệu nào? SCHEMA foocó thể tồn tại trong cơ sở dữ liệu khác nhau?
J86

2
@ J86: chỉ áp dụng cho cơ sở dữ liệu hiện tại - nơi lệnh được thực thi.
Erwin Brandstetter

1
@ErwinBrandstetter Tôi có thể cấp quyền truy cập cho các bảng / chuỗi trong tương lai cho app_user (đọc-ghi) với điều kiện là các bảng sẽ được tự động tạo bởi một người dùng chuyển đổi chuyên dụng khác (di chuyển đường bay được chạy khi khởi động ứng dụng) không?
lexeme

43

Câu trả lời của tôi tương tự như câu trả lời này trên ServerFault.com .

Bảo thủ

Nếu bạn muốn tiết chế hơn việc cấp "tất cả các đặc quyền", bạn có thể muốn thử một cái gì đó tương tự hơn.

GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA public TO some_user_;
GRANT EXECUTE ON ALL FUNCTIONS IN SCHEMA public TO some_user_;

Việc sử dụng public ở đó đề cập đến tên của lược đồ mặc định được tạo cho mọi cơ sở dữ liệu / danh mục mới. Thay thế bằng tên của chính bạn nếu bạn đã tạo một lược đồ.

Truy cập vào Lược đồ

Để truy cập vào một lược đồ, đối với bất kỳ hành động nào, người dùng phải được cấp quyền "sử dụng". Trước khi người dùng có thể chọn, chèn, cập nhật hoặc xóa, trước tiên người dùng phải được cấp "quyền sử dụng" đối với một lược đồ.

Bạn sẽ không nhận thấy yêu cầu này khi lần đầu tiên sử dụng Postgres. Theo mặc định, mọi cơ sở dữ liệu có một lược đồ đầu tiên được đặt tên public. Và mọi người dùng theo mặc định đã tự động được cấp quyền "sử dụng" đối với lược đồ cụ thể đó. Khi thêm lược đồ bổ sung, bạn phải cấp quyền sử dụng một cách rõ ràng.

GRANT USAGE ON SCHEMA some_schema_ TO some_user_ ;

Trích từ tài liệu Postgres :

Đối với các lược đồ, cho phép truy cập vào các đối tượng có trong lược đồ được chỉ định (giả sử rằng các yêu cầu đặc quyền riêng của đối tượng cũng được đáp ứng). Về cơ bản, điều này cho phép người được cấp quyền "tra cứu" các đối tượng trong lược đồ. Nếu không có quyền này, vẫn có thể xem tên đối tượng, ví dụ bằng cách truy vấn các bảng hệ thống. Ngoài ra, sau khi thu hồi quyền này, các phần mềm phụ trợ hiện có có thể có các câu lệnh đã thực hiện tra cứu này trước đó, vì vậy đây không phải là cách hoàn toàn an toàn để ngăn truy cập đối tượng.

Để biết thêm thảo luận, hãy xem Câu hỏi, Việc sử dụng CẤP PHÉP TRÊN SCHEMA chính xác là gì? . Đặc biệt chú ý đến câu trả lời của chuyên gia Craig Ringer của Postgres .

Đối tượng hiện tại so với tương lai

Các lệnh này chỉ ảnh hưởng đến các đối tượng hiện có. Các bảng và các bảng tương tự bạn tạo trong tương lai sẽ nhận được các đặc quyền mặc định cho đến khi bạn thực hiện lại các dòng đó ở trên. Xem câu trả lời khác của Erwin Brandstetter để thay đổi các giá trị mặc định do đó ảnh hưởng đến các đối tượng trong tương lai.


1
ngoài hai khoản trợ cấp ở trên, cần thêm một khoản trợ cấp nữa: GRANT USAGE ON SCHEMA public TO some_user_;
Ning Liu

1
@NingLiu Cảm ơn rất nhiều vì đã chỉ ra CÁCH SỬ DỤNG HẤP DẪN và đã dạy tôi điều đó. Tôi đã thêm một phần vào Câu trả lời.
Basil Bourque

CẤP QUYỀN SỬ DỤNG TRÊN SCHEMA là những gì tôi đang tìm kiếm.
Basil Musa
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.