XXX，你好，我想给一个用户某张表的只读权限，你有空看看吗？

于是，我就远程连上去，本来几分钟能搞定的事情，半个小时、一个小时过去了，笑容逐渐凝固……

几经周折，终于找到问题所在，原来是public作怪，哈哈

今天，我们就模拟客户的实际环境，来和大家聊聊public如何作祟，以及我们平时应该如何正确对待public，请看下文。

一、环境描述

客户想给某个数据库某张表的只读权限，然后就新建用户－－＞映射数据库－－＞数据库下用户的安全对象选中表－－＞给选择权限。

步骤貌似没问题啊，可这个用户就是能更改、能插入，很头疼……

二、模拟操作

2．1 本地环境新建用户并授权

－－1、创建用户dsz＿test（映射数据库为dsz）

－－2、授予tb＿Ts表的只读权限

－－3、测试（用dsz＿test登录）

－－4、图形化界面显示

可以看到，我本地的 dsz＿test  登录只可以看到tb＿Ts 表，拒绝了其他读写等权限

2．2 模拟客户环境新建并授权

－－1、创建用户并授权

－－2 、测试（用dsz＿test1登录）

－－3、图形化界面显示

妈耶，dsz＿test1  登录后可以看到另外一张表，而且竟然可以update，玩我呢！！！

三、分析原因

3．1 查看本地用户权限

3．2 查看客户环境权限

貌似一毛一样，真的见鬼了吗？

我们再仔细分析，对于新建的用户，我们不是别的角色成员，也不是别的角色领袖……等等，角色？对啊，不是还有个public的东东存在吗？？？

3．3 查看本地Public权限

3．4 查看客户Public权限

嗷，是不是感觉到什么了， 之所以dsz＿test1能对dsz＿1表肆意妄为，是因为public的锅啊。

四、Public

每个数据库的所有用户都是public角色，用户同样不能退出public角色成员。

默认拥有VIEW ANY DATAbase和CONNECT权限

可以通过REVOKE VIEW ANY DATAbase FROM PUBLIC回收public权限

五、总结

本次权限问题就是因为客户授予public指定表的更新选择权限，又因为所有用户都是public的角色，所以，只能回收掉public对该表的更新选择权限：

然后再用dsz＿test1登录测试，结果令人满意。如下：

建议：SQL server的public权限很特殊，每个用户都会继承它所拥有的权限，所以不建议对其授予相应的权限，必要情况下，建议VIEW ANY DATAbase也回收。