我正在使用Laravel 9和PostgreSQL 15作为我个人博客项目的一部分。在设置过程中，我最终提出了几个问题。
- 如果我正在设置一个单独的角色(根据PostgreSQL文档的这一部分，PostgreSQL中的用户是具有
LOGIN特权的角色)，该角色的适当属性设置是什么，因此它不是超级用户(使用root或postgres角色无处不在通常被认为是一个坏的做法，因为这些角色的全方位自由)，但足以让Laravel管理数据库? - 是否需要为同一个项目创建多个角色以实现更灵活的权限管理?如果是，使用Laravel的典型多角色方法是什么?
您需要一个在模式上具有create特权的用户，以便能够创建表并使用它们。实现这一目标的一种方法是创建一个特定于应用程序的模式，并让应用程序用户拥有它:
create user app_user password '*******';
create schema app_schema authorization app_user;
alter user app_user set search_path = 'app_schema';
app_user可以在app_schema中创建和修改表，并且作为这些表的所有者，他们也可以修改其中的数据。
通过将search_path设置为app_schema，表在应用程序中不需要是模式限定的。
请注意，在Postgres 15之前，每个用户在public模式中都具有这些权限(因为它们被授予了伪角色"public")。但出于安全原因，该视频被删除了。即使在旧版本上，出于安全原因，遵循上述模式也是一个好主意。如果您在旧版本上执行此操作，您可能希望完全删除公共模式，或者至少删除其上的特权:
remove all privileges on schema public from public;
在某些环境中，表的所有者和用于执行DML的DB用户是独立的用户/角色，并且不允许所有者登录，因此无法利用
create role app_owner with nologin;
create user app_user password '*******';
create schema app_schema authorization app_owner;
grant usage on app_schema to app_user;
alter user app_user set search_path = 'app_schema';
-- Apply default grant for tables created by app_owner
alter default privileges
for role app_owner
in schema app_schema
grant select,insert,update,delete on tables
to app_user;
-- if you are still using the outdated serial pseudo-type
-- allow access to all sequences
-- this is not necessary if using identity columns
alter default privileges
for role app_owner
in schema app_schema
grant select,usage on sequences
to app_user;
要创建表，您需要以超级用户身份登录，然后使用set rol app_owner在模式中创建/修改表。
这种设置使模式迁移更加复杂。当您的应用程序包含模式迁移时，这几乎是不可能使用的，因为app_owner无法登录，并且授予app_user该角色将破坏整个设置。
我个人认为这不会带来更多的安全性。毕竟，一个能运行delete from customer;的攻击者的威胁并不比一个能运行drop table customer;的攻击者的威胁小。