Đặc quyền cho chủ sở hữu cơ sở dữ liệu; người dùng ứng dụng


15

Phiên bản nhanh:

Tôi nên phát lệnh nào để cho phép chủ sở hữu cơ sở dữ liệu cho phép nó truy cập các bảng trong cơ sở dữ liệu này và điều này có thể được thực hiện từ tài khoản của chủ sở hữu đó không?


Phiên bản dài hơn:

Tôi đang tạo một cơ sở dữ liệu trên RDS. Tôi có một người dùng 'root' mà tôi đã cấu hình với Amazon.

Amazon tự động tạo ra vai trò nhóm 'rds_superuser' rất đặc quyền, nhưng thực tế không phải là siêu người dùng.

Tôi đang tạo một cơ sở dữ liệu và người dùng cho ứng dụng như sau:

create database master_integration;
CREATE ROLE master_application LOGIN ENCRYPTED PASSWORD '...' VALID UNTIL 'infinity';
GRANT ALL ON DATABASE master_integration TO GROUP rds_superuser WITH GRANT OPTION;
GRANT ALL ON DATABASE master_integration TO GROUP master_application;

\c master_integration;
ALTER DEFAULT PRIVILEGES GRANT INSERT, SELECT, UPDATE, DELETE, TRUNCATE, REFERENCES, TRIGGER ON TABLES TO rds_superuser;

Tôi đã cập nhật kịch bản này để phản ánh các đề xuất của Craig Ringer về cách tôi nên xử lý việc này.

Khi ứng dụng kết nối (với thông tin đăng nhập master_application), nó sẽ tạo (và do đó sở hữu) các bảng.

Vấn đề của tôi là tôi không thể sử dụng đăng nhập quản trị (rootish) của mình để chạy truy vấn vì người dùng đó không có đặc quyền trên bảng.

Tôi đã có thể giải quyết vấn đề này trước đây bằng cách chạy các mục sau từ tài khoản ứng dụng:

GRANT ALL privileges ON ALL TABLES IN SCHEMA public to rds_superuser;

Nhưng có vẻ như rất khó để có một người dùng cấp dưới cấp quyền riêng tư cho người dùng quản trị.

Vậy ... Có một lệnh mà tôi có thể chạy trước hoặc sau khi tôi tạo các bảng từ ứng dụng để đảm bảo rằng chủ sở hữu của cơ sở dữ liệu có thể truy cập các bảng trong cơ sở dữ liệu?


cập nhật sau khi thử lại các đặc quyền mặc định thay đổi ...

Điều này vẫn không cấp quyền truy cập vào các bảng; Tôi thấy nó được đề xuất ở nơi khác và nó hoàn toàn có ý nghĩa, nhưng nó không hiệu quả với tôi. Từ một vỏ psql:

master_integration=> \ddp
                           Default access privileges
      Owner       | Schema | Type  |             Access privileges             
------------------+--------+-------+-------------------------------------------
 integration_root |        | table | integration_root=arwdDxt/integration_root+
                  |        |       | rds_superuser=arwdDxt/integration_root
(1 row)

master_integration=> \dp users
                           Access privileges
 Schema | Name  | Type  | Access privileges | Column access privileges 
--------+-------+-------+-------------------+--------------------------
 public | users | table |                   | 
(1 row)

integration_root là người dùng superuser-ish của tôi và người dùng là một bảng trong cơ sở dữ liệu của tôi.


Cập nhật

Tôi đã nhận được một phản hồi khá vô dụng từ một người nào đó ở Amazon.

Họ yêu cầu tôi gọi ALTER DEFAULT PRIVILEGES từ thông tin đăng nhập master_application. Mặc dù điều này có thể hoạt động, nhưng nó sẽ không trả lời câu hỏi của tôi (đó là cách tôi thực hiện điều này chỉ xảy ra từ tài khoản rds_superuser).

Tôi yêu cầu họ làm rõ điều này và họ đã đi.

Câu trả lời:


9

Bạn muốn ALTER DEFAULT PRIVILEGES .

Đưa rds_superuser quyền truy cập mặc định cho tất cả các bảng mới.

Điều này chỉ ảnh hưởng đến các bảng được tạo sau ALTER. Đối với các bảng hiện có, bạn phải có GRANTquyền.


Tôi đã cố gắng để làm điều này. Tôi đã nói từ này kém trong câu hỏi ban đầu, tôi đã chỉnh sửa nó để hiển thị chính xác lệnh mà tôi đang thực hiện. Tôi đã nhận được một cái gì đó sai?
Andy Davis

Nó chỉ ảnh hưởng đến bảng được tạo ra sau khi các ALTER. Khi nào bạn làm điều đó? Đối với các bảng hiện có, bạn phải có GRANTquyền.
Craig Ringer

Tôi đã thay đổi các quyền riêng tư mặc định, sau đó tạo các bảng. Tôi sẽ thử lại lần nữa, có lẽ tôi đã phạm sai lầm.
Andy Davis

Vẫn không có may mắn với điều này, mặc dù nó hoàn toàn giống như lệnh nên giải quyết vấn đề. Tôi đã cập nhật lệnh để bao gồm đầu ra từ \ ddp và \ dp từ một trong các bảng.
Andy Davis

Thật kỳ quặc Bạn có thể tái tạo vấn đề trong một PostgreSQL thông thường (không phải RDS) không?
Craig Ringer

0

Lược đồ công cộng được cho là hiển thị bởi tất cả người dùng. Bạn không nên hạn chế quyền của lược đồ công cộng đối với chỉ một nhóm.

Vì vậy, nếu bạn không sử dụng:

GRANT ALL ON SCHEMA public TO GROUP rds_superuser WITH GRANT OPTION;

Bạn có thể làm việc một cách an toàn với lược đồ công cộng với tất cả các tài khoản.

Nếu bạn không muốn các tài khoản cụ thể làm xáo trộn các bảng lược đồ công khai của mình, thì hãy tạo một vai trò mới (cho người dùng ứng dụng của bạn) và thu hồi các quyền từ vai trò cụ thể này trong lược đồ công khai. Cái gì đó như:

CREATE USER mywebuser WITH PASSWORD '*****';
REVOKE ALL PRIVILEGES ON SCHEMA public FROM mywebuser;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO mywebuser; (or whatever rights you need to provide)

Không phải là cách khác như bạn cố gắng để làm điều đó.


Huh? Một GRANTkhông bao giờ nên có thể làm giảm quyền truy cập. Tôi không tin chắc. Lưu ý rằng các quyền trên một lược đồ không được kế thừa bởi các bảng mới trong lược đồ đó, do đó, có quyền truy cập vào publiclược đồ không có nghĩa là bạn có thể sử dụng các bảng trong đó.
Craig Ringer

Cuối cùng tôi đã được dùng thử và nó không giúp gì được cho tình hình.
Andy Davis

Tôi đã chỉnh sửa câu hỏi để loại bỏ Grant mà @Aleandros đang đề cập đến. Nó dường như không phải là vấn đề, nhưng tôi nghĩ đó là một sự xao lãng.
Andy Davis
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.