对象上的权限,但那是被动反应的方式而非积极主动的方式――你是在查找当前访问级别上哪里出错了,而不是事先停止不希望发生的访问。
最后,但并非最不重要的,是AS关键字。该关键字处理的是一个登录名属于多个角色的问题。
接下来,我们来看一、两个例子。后面将看到,我们已 经创建的TestAccount账户,基于其是Public角色(所有的数据库用户都属于的东西,并且,无法从中移除)中的成员而拥有了一些访问权限。然 而,尚有大量的项目是TestAccount不具有访问权限的(由于Public是TestAccount唯一属于的角色,因此,Public也不具有那 些权限)。
先从以TestAccount用户登录开始。然后在Region表上尝试一个SELECT语句:
很快,你将收到来自SQL Server的消息,告知:你正在尝试去到你所不应该访问的地方。
单独以sa登录――如果你愿意,也可以在同一个查询编辑器实例中,通过选择菜单“文件”→“连接”,来完成这件事情。然后,为新的连接选择“SQL Server身份验证”,并用正确的密码以sa身份登录。现在,执行GRANT语句:
接着,切换回TestAccount连接(要记住,以什么用户进行连接的信息显示在连接窗口的标题栏中),然后,再尝试执行SELECT语句:这一次,得到了好得多的结果:
我们继续尝试另外的语句。这一次,我们在EmployeeTerritories表上运行相同的测试和命令:
该语句执行失败――这同样是由于你不具备相应的权限所致,因此,授予用户该表上的权限:
然后,再次运行SELECT语句,一切进展顺利:
不过,若要再添加一点变化,尝试在这个表中执行INSERT:
SQL Server立即会让我们走开――我们不具备必要的权限,因此,授予用户相应的权限(使用sa连接):
现在,再次运行INSERT语句:
一切进展顺利。
2.DENY
DENY明确阻止用户获得目标对象上指定的访问 权限。DENY的关键所在是,它将覆盖任何GRANT语句。由于用户可以属于多个角色(马上将对此进行讨论),因此,一个用户可能属于被授予了访问权限的 角色,但同时又受DENY的影响。如果用户个人的权限和基于角色成员身份所获得的权限混合在一起,DENY和GRANT同时存在于其中,那么DENY总是 优先的。简言之,如果用户或用户所属的任何角色在权限问题上有DENY出现,则用户将不能使用在那个对象上的访问权限。