本文首发微信公众号：码上观世界

中国“红武士”——刘粹刚

东方古国，炎黄子孙，五千余载，历史文明;。

诗礼传承，世界同钦，仁爱与人，道德长青。

濒江近海，有我南京，十朝都会，物阜文丰。

秦淮灯火，玄武清风，紫金绮丽，幕府山雄。

岁逢丁丑，噩耗惊逢，东瀛倭鬼，炮火加城。

屋坍梁折，百镇荡平，千乡闻哭，遍地哀鸣。

刀亡枪杀，不论军民，奸淫掳掠，丧尽良心。

朗朗书声，为之顿绝，哀哀母号，泪有血痕。

夫妻骤离，邻家同死，妇孺无别，老幼无分。

剜目斩首，剖腹流肠，举火而焚，掘土以坑。

淫妻淫女，直如禽兽，失心失德，竞赛杀人。

四世之家，为之遽灭，千家之镇，一日夷平。

月自壬子，四十二天，杀我同胞，三十万人。

秦淮玄武，血水同流，慕府紫金，遍野尸横。

十朝都会，已成地狱，千古文明，惨作屠城。

地覆同挡，天坠同擎，中华不死，万众一心。

上下同奋，日月同明，兄弟携手，急以见诚。

浴血八载，抗日有成，中华大地，始见光明。

辟地开天，祖国新生，改革开放，华夏复兴。

四海翘首，五洲叹惊 ，大同在梦 小康初成。

巡洋探月，强国富民，民心大振，巨龙飞腾。

时逢盛世，国耻长铭，强军强国，只为和平。

今开公祭，以国之名，举杯三酹，乃慰亡灵。

史无覆辙，人要前行，开来继往，更待后生。

呜呼，伏维尚飨。

（为纪念1937.12.13而发）

以下为正文。

Hive早期默认的授权模型基于类似传统RDBMS的用户、组、角色这样的权限概念，并且将对数据库、表、分区的操作权限分配给它们。但是，跟传统的RDBMS不同的是，Hive的权限模型是有缺陷的，不能够完全控制数据的访问，因为Hive的元数据和数据本身是分离的，元数据存储在关系数据库，而数据存储在HDFS等分布式系统中，且是可以独立访问的。于是带来一些问题，比如：

• 给某用户分配了某表的查询权限，但是却无法读取数据表的数据。

• 撤销了某用户查询某表的权限，但用户仍然能够读取其数据。

Hive Metastore作为独立的元数据服务，可以被不同的引擎（Hive、Spark、Flink、Trino等）调用，如果在引擎端没有做权限控制，Hive Metastore将像肉鸡一样存在，势必造成很大的安全问题。比如任何人都可以随意的查询、创建，修改甚至删除元数据，有些操作比如drop还可能造成数据本身的破坏。

但是Hive社区无法提供一种全能的权限控制方式，只是通过扩展方式提供了一种适应不同的场景的权限控制途径。主要有两种类型的权限控制方式：

1 通过Hcatcalog API访问hive数据的方式，实际是通过访问metastore元数据的形式访问hive数据，这类有MapReduce，impala，pig，Spark SQL，hive Command line等方式，基于这种方式的权限控制称为：Storage Based Authorization in the Metastore Server。

2 通过hiveserver2的方式访问hive数据，基于这种方式的权限控制称之为：SQL Standards Based Authorization in HiveServer2

基于存储的权限控制方式是解决Hive Metastore本身的权限控制的推荐方案，其思路是Hive Metastore元数据底层对应是存储路径，比如库表底层可以是hdfs存储目录，只要用户具备读写hdfs存储目录的权限，那自然具备了读写库表的权限，这种思路很直观，权限控制也很彻底，其他Hadoop应用如果想访问该库表，就必然具备底层目录的相应权限，无法绕过，因此提供了权限共享的机制。使用起来很方便，只要在metastore侧的hive-site.xml文件中添加如下配置项即可：

<property><name>hive.security.metastore.authorization.manager</name><value>org.apache.hadoop.hive.ql.security.authorization.StorageBasedAuthorizationProvider</value></property><property><name>hive.security.authorization.enabled</name><value>true</value>
</property>

它基于HDFS的ACL授权模型来为用户授权，比如需要给某用户分配warehouse目录的读、写、执行权限，可以这样设置:

hadoop fs -setfacl -m user:test:rwx /user/hive/warehouse

然而基于存储的授权模型也有不足：

• 一些元数据接口（主要是读相关的接口）的权限控制没有实现；

• 目录下新增的分区和文件操作权限并不能被除了owner用户以外的其他同组用户继承；

• 无法进行列级别的精细化权限控制

基于标准SQL的授权方式能够提供精细化的权限控制，使用用户熟悉的grant/revoke语句进行授权。基于标准SQL的权限验证是在hiveserver2端进行SQL编译期间完成的，基于标准SQL的授权使用可以在配置文件hiveserver2-site.xml中添加以下配置项：

<property><name>hive.security.authorization.manager</name><value>org.apache.hadoop.hive.ql.security.authorization.plugin.sqlstd.SQLStdHiveAuthorizerFactory</value></property><property><name>hive.security.authenticator.manager</name><value>org.apache.hadoop.hive.ql.security.SessionStateUserAuthenticator</value></property><property><name>hive.security.authorization.enabled</name><value>true</value>
</property>

在HiveServer2端，基于标准SQL的配置是当前的默认推荐授权方式。虽然它也可以应用于Hive Cli，但是只要用户拥有了对HDFS的访问权限就可以绕过这套授权模型，所以为了避免给用户造成安全误导，默认禁用。

使用基于标准SQL的授权方式也有一些限制，比如：

• 一些命令将被禁用，比如 dfs, add, delete, compile, 以及 reset ；

• 修改Hive Configuration的set命令所能修改的配置项被限制在较小的范围（hive.security.authorization.sqlstd.confwhitelist）；

• add/drop函数和宏 被限制到admin 角色；

• transform语法被禁用

基于存储的授权方式常用于Metastore的权限控制，基于SQL的授权方式常用于精细化权限控制，但是如果对精细化权限控制不要求，也是可以基于存储的授权方式来提供一致性的权限控制，然而也可以将两者结合起来同时使用。基于SQL的授权方式还可能存在一个问题：如果hive.server2.enable.doAs 设置为false，那么操作HDFS的用户将为一个固定的超级用户（通过HADOOP_USER_NAME环境变量指定），此时基于存储的授权方式将变成一个空壳，起不到权限验证的作用，此时只能用当前提交Hive SQL的用户来操作HDFS，为此HiveServer2以及Metastore必须共享同一套用户（组）体系。此外，Hive Metastore权限控制还有第三种方案：基于插件机制的Ranger，因为它不仅能实现精细化的权限控制，而且还支持基于Web UI操作的多种数据源的权限控制，目前获得较广泛的使用，但是Ranger不支持Hive Metastore，本文后续介绍如何基于Ranger来开发支持Hive Metastore。