视图/同义词与基础表的特权答案

【问题标题】：Privileges on views/synonyms vs on underlying tables视图/同义词与基础表的特权
【发布时间】：2016-08-05 20:30:29
【问题描述】：

用户是否需要SELECT /INSERT/DELETE/UPDATE 等视图和基础表的权限才能执行这些操作？或者任何一个表/视图的权限就足够了？

换句话说，假设用户 A 拥有表 T 和视图 V（由 T 构建）。如果用户 B 在 V 上具有 SELECT 权限，如果他在 T 上没有 SELECT 权限，他是否可以执行 SELECT，反之亦然？如果他可以，那是否意味着 View 特权“覆盖”了 table 特权，因为 A 没有给他超过 T 的权利？

更新

在一个相关问题中，同义词怎么样？根据我在一本书中的理解，用户需要SELECT 同义词和基础表的特权。这将不同于视图。

另一方面，Oracle 似乎表明同义词的行为类似于视图。

可以授予用户对同义词或视图的 SELECT 权限没有被明确授予 SELECT 权限原始表

更新 2

按照大家的回答，我们只需要视图的权限来选择表（至少视图从表中看到的）并且不需要表的权限，让我们考虑这种情况：

表 T 属于 A

T 到 B 上的 GRANT SELECT（无 GRANT OPTION）

B 创建视图 V AS SELECT * FROM A.T

B 在 V 到 C 上授予选择

C 执行 SELECT * FROM B.V

按照你说的，C可以从V中选择，因此相当于从T中选择。这是作弊吗？ B 有效地让 C 看到 A.T，尽管 C 没有 T 的权利并且 B 没有 GRANT OPTION。某处是否存在安全漏洞？

【问题讨论】：

您应该区分视图的第三个用户和所有者。当用户使用视图时，他只需要视图所有者授予用户的视图的权限。视图的所有者必须对该视图使用的表具有权限。他必须有权授予这些权限（授予选项）或必须拥有这些表，GRANT
让我们有 3 个用户：t_owner 拥有表，v_owner 拥有视图和 n_user。要创建视图，v_owner 需要对视图中使用的表从 t_owner 具有选择权限。要从视图中选择 n_user 需要从视图中选择权限。要授予此特权，v_owner 需要来自 t_owner 的授予。现在应该做的是：从 t_owner GRANT SELECT ON table_name TO v_owner WITH GRANT OPTION; , 从 v_owner GRANT SELECT ON view_name TO n_user;
谢谢大家。我已经更新了我的问题以获取更多详细信息。随意详细说明。

标签： oracle view oracle11g privileges synonym

【解决方案1】：

视图的基本用途之一是保护隐私。基表可能包含某些用户不需要查看的机密信息（例如，在雇员表中，您可能有薪水）。一些用户需要访问查询（选择）或更新基表中的某些字段，而无权访问完整信息。例如：选择电话号码，或更新地址（但无权查看工资或奖金）。然后，将创建一个视图并授予这些用户仅对视图的“选择”和“更新”权限，而不是对基表的权限。（选择仍然与基表相反，但 COLUMNS 将仅限于视图中包含的那些......可以/将要对基表进行更新，但同样，仅针对视图中包含的列中的值。 ) 视图不仅可以限制列，还可以限制行 - 例如，在视图中使用 WHERE 子句，您可以将 CEO 完全排除在视图之外。

因此，视图的主要用途之一正是基于此：某些用户可能对视图具有特权，但对基表没有特权。

【讨论】：

【解决方案2】：

是的。通常视图以视图所有者的身份运行，用户以视图的权限运行。所以用户 b 只需要访问视图。

但是，在查看此类问题时，您可能还想了解行级安全性。这通过授予给定用户或组访问表的一部分来工作（即在查询结束时有效地执行 where 子句）。根据您的用例，管理起来可能更简单或更复杂。

【讨论】：