最近，我站点的审计结果发现，默认情况下将 PUBLIC 分配给所有创建的模式是一个很大的风险，因为当创建新用户时，即使我们只分配 CONNECT 和 RESOURCE 角色，模式仍然可以插入/更新/删除甚至系统模式对象的表。
即使在查询 dba_sys_privs 时，没有分配给该被授予者“PUBLIC”的系统权限，而 dba_tab_privs 显示其他权限，这本身就是一种风险。但是，甲骨文在一次金属链接中表示，撤销 PUBLIC 有其自身的后果。
我确实尝试使用 SCOTT 模式在其中一个 SYSTEM 表中插入一行，它确实通过了。
从正常模式中撤销 PUBLIC 对功能的影响有多大？如果不处理，风险有多大？或者我应该为默认模式以外的应用程序模式小心地撤销它们？
如果这是一个安全漏洞，那么默认分配 PUBLIC 有什么用？
您不能撤销
public用户的伪角色。每个用户总是有public.您可以撤销该
public角色的权限。第一个问题是 Oracle 是否默认授予这些特权，在这种情况下，撤销它们可能会很困难。例如，它可能会中断升级和补丁和/或由未来的升级和补丁重新授予。有一些方法可以减少默认的赠款集，public但这往往是一项相当多的工作，而收益却很少：在默认的 Oracle 安装中，一个用户
create session不能创建对象，不能读取另一个用户模式中的对象，当然也不能修改另一个用户模式中的数据。只有当您组织中的某个人足够疯狂地去做诸如授予之类的事情update any table时，public才会发生这种情况。如果有人向公众授予了甲骨文附带的大量强大特权，那么在没有令人信服的理由的情况下，这将是一个令人担忧的问题。另一方面，如果用户除了
create session可以修改system表中的数据之外没有其他权限，那么这意味着您（或您组织中的某个人）已向该public角色授予了大量对象权限。如果没有为每一项拨款提供相当令人信服的理由，那肯定会令人担忧。这确实应该通过为您的应用程序创建适当的角色并将这些角色授予任何需要它们的用户来完成。如果您在system模式中创建对象，那将是另一个问题——只有 Oracle 应该在sysor中创建对象system。实际应用程序不应使用
connectorresource角色。如果您查看这些角色授予的实际权限，它们可能比您预期的要多得多也少得多。此外，它们会随着版本的变化而变化——Oracle 一直在锁定后续版本中的角色，因为人们在不了解这些授权的含义的情况下自由地授予它们。该
public角色之所以存在，是因为默认情况下应该为每个用户正确地授予某些特权。例如，您可能希望新用户能够查询user_tables以查看他们拥有的表或all_tables查看他们对哪些表具有特权。如果每个应用程序都必须附带它需要查询的每个数据字典表的完整列表（其中一些会根据不同的 JDBC/ODBC/OLE DB/ 等提供程序实现某些 API 功能的方式而有所不同），那将是非常烦人的。默认情况下，拥有一个小的功能基线很有用。