• 4.6.3 视图的授权
  • 创建视图的用户不会得到该视图上的全部权限
  • 用户对视图的权限从定义视图的关系中继承得到
  • 函数和过程的权限默认和创建者的权限一样
  • 设置函数和过程的权限与调用者的权限一样

4.6.3 视图的授权

在我们的大学例子中,考虑有一位工作人员,他需要知道一个给定系(比如Geology系)里所有员工的工资。该工作人员无权看到其他系中员工的相关信息。因此,该工作人员对instructor关系的直接访问必须被禁止。但是,如果他要访问Geology系的信息,就必须得到在一个视图上的访问权限,我们称该视图为geo_instructor,它仅由属于Geology系的那些instructor元组构成。该视图可以用SQL定义如下:

create view geo_instructor
as(
    select *
    from instructor
    where dept_name='Geology'
);

假设该工作人员提出如下SQL查询:

select *
from geo_instructor;

显然,该工作人员有权看到此查询的结果。但是,当查询处理器将此查询转换为数据库中实际关系上的査询时,它产生了一个在instructor上的查询。这样,系统必须在开始查询处理以前,就检查该工作人员查询的权限。

创建视图的用户不会得到该视图上的全部权限

创建视图的用户不需要获得该视图上的全部权限。他得到的那些权限不会为他提供超越他已有权限的额外授权。

用户对视图的权限从定义视图的关系中继承得到

例如,如果一个创建视图的用户在用来定义视图的关系上没有update权限的话,那么他不能得到视图上的update权限。
如果用户创建一个视图,而此用户在该视图上不能获得任何权限,系统会拒绝这样的视图创建请求。
在我们的geo_instructor视图例子中,视图的创建者必须在instructor关系上具有select权限。

函数和过程的权限默认和创建者的权限一样

正如我们将在5.2节看到的那样,SQL支持创建函数和过程,在函数和过程中可以包括查询与更新。在函数或过程上可以授予execute权限,以允许用户执行该函数或过程。在默认情况下,和视图类似,函数和过程具有其创建者所拥有的所有权限。在效果上,该函数或过程的运行就像其被创建者调用了那样。

设置函数和过程的权限与调用者的权限一样

尽管此行为在很多情况下是恰当的,但是它并不总是恰当的。从SQL:2003开始,如果函数定义有一个额外的sql security invoker子句,那么它就在调用该函数的用户的权限下执行,而不是在函数定义者的权限下执行。这就允许创建的函数库能够在与调用者相同的权限下运行。

原文链接: 4.6.3 视图的授权