4.6.3 视图的授权
4.6.3 视图的授权
在我们的大学例子中,考虑有一位工作人员,他需要知道一个给定系(比如Geology
系)里所有员工的工资。该工作人员无权看到其他系中员工的相关信息。因此,该工作人员对instructor
关系的直接访问必须被禁止。但是,如果他要访问Geology
系的信息,就必须得到在一个视图上的访问权限,我们称该视图为geo_instructor
,它仅由属于Geology
系的那些instructor
元组构成。该视图可以用SQL
定义如下:
1 | create view geo_instructor |
假设该工作人员提出如下SQL
查询:
1 | select * |
显然,该工作人员有权看到此查询的结果。但是,当查询处理器将此查询转换为数据库中实际关系上的査询时,它产生了一个在instructor
上的查询。这样,系统必须在开始查询处理以前,就检查该工作人员查询的权限。
创建视图的用户不会得到该视图上的全部权限
创建视图的用户不需要获得该视图上的全部权限。他得到的那些权限不会为他提供超越他已有权限的额外授权。
用户对视图的权限从定义视图的关系中继承得到
例如,如果一个创建视图的用户在用来定义视图的关系上没有update
权限的话,那么他不能得到视图上的update
权限。
如果用户创建一个视图,而此用户在该视图上不能获得任何权限,系统会拒绝这样的视图创建请求。
在我们的geo_instructor
视图例子中,视图的创建者必须在instructor
关系上具有select
权限。
函数和过程的权限默认和创建者的权限一样
正如我们将在5.2节看到的那样,SQL
支持创建函数
和过程
,在函数和过程中可以包括查询
与更新
。在函数或过程上可以授予execute
权限,以允许用户执行该函数或过程。在默认情况下,和视图类似,函数和过程具有其创建者所拥有的所有权限。在效果上,该函数或过程的运行就像其被创建者调用了那样。
设置函数和过程的权限与调用者的权限一样
尽管此行为在很多情况下是恰当的,但是它并不总是恰当的。从SQL:2003
开始,如果函数定义有一个额外的sql security invoker
子句,那么它就在调用该函数的用户的权限下执行,而不是在函数定义者的权限下执行。这就允许创建的函数库能够在与调用者相同的权限下运行。