Question

根据我一直在阅读的有关权限的信息，我了解到在为角色分配任何权限之前撤销权限是很好的。我有一个名叫appuser的用户，我做了以下事情：

REVOKE ALL PRIVILEGES ON SCHEMA PUBLIC FROM GROUP PUBLIC;

GRANT SELECT
  ON public.table1 TO appuser;

GRANT SELECT
  ON public.table1_id_seq TO appuser;

GRANT SELECT
  ON public.table2 TO appuser;

GRANT SELECT
  ON public.table2_id_seq TO appuser;

我这样做是为了希望删除附加到任何新添加的用户的任何权限，自动成为公共角色成员资格的一部分。相反，我得到一个错误，appuser的效果没有架构的权限。然而，这是我对这个错误的误解。 1. PgAdminIII在此模式的“组角色”下不显示公共角色 2. appuser似乎不是名为public的组的成员（因为它在接口中不存在）。 3. appuser的权限被明确授予，即使它是公共角色的一部分

那么......是否存在某种被称为“公共”的隐式组角色正在影响该用户的权限？我不明白发生了什么。我还试图找出从pgAdminIII命令行显示组角色成员资格的位置，但也没有运气。顺便说一句，我只是颠倒了第一个命令（即在公共集团公共场所授予所有特权）;然而，这基本上解开了我最初尝试做的事情（即简单地锁定表格）。

有什么想法吗？

更新：我有预感，我发现了问题所在。我不认为appuser对架构有权限。如果我没弄错，必须先授予架构权限，然后才能访问架构下的任何对象。

Answer 1

好的，所以这里的答案有点复杂，为什么事情的行为与他们的行为方式有关，并且在某种程度上讨论PostgreSQL安全模型可能是值得的。

PUBLIC不是角色或群组，而是保留词。权限的工作方式是授予当前继承角色或PUBLIC的访问权限。实际上，在我构建包装PostgreSQL角色的框架时，我实际上已经被它咬了。

一般来说，我认为你想做的事情如下：

不要让每个人都登录数据库。

REVOKE CONNECT ON DATABASE mydb FROM public;

我认为您所做的是其他事情，即撤消架构中的权限（但不撤销架构中的表！），因此保留PUBLIC访问权限以获取该架构中表的默认权限。这可能是也可能不是你想要的。无论如何，您需要向架构添加权限才能返回到您所在的位置。

现在我不完全确定你在这里要做什么。如果要完全锁定数据库，则还需要对所有表执行相同操作。否则，如果你：

 CREATE USER foo;
 GRANT USAGE ON SCHEMA PUBLIC TO foo;

然后，foo将可以访问PUBLIC对表的所有权限。

在PostgreSQL中锁定公共组角色

1 个答案: