zookeeper 权限概述

buhao

　　老样子，先上连接，第一个是淘宝综合业务平台的（前几个月还叫通用产品团队呢我记得）
　　
　　http://rdc.taobao.com/team/jm/archives/947，其实基本上需要的他这里都有了，只是……太专业了，什么都说了唯独没说要怎么用。另一个是http://ec2-23-21-252-232.compute-
　　
　　1.amazonaws.com/wordpress/?p=14，写的基本上也到位了，就是格式太差，看了半天看不到重点，所以今天再写一篇不完全自主知识产权的文章，稍微总结一下zookeeper中的权限管理。
　　其实综合业务（每次都想打“通用产品”）的文章写的已经很具体了不过可以稍微总结一下：
　　

　　先来看下ACL的数据结构：
每一个znode节点上都可以设置一个访问控制列表，数据结构为List

ACL
+--perms int （allow What）
+--id Id
    +--scheme String （Who）
    +--id String      （How）
一个ACL对象就是一个Id和permission对，用来表示哪个/哪些范围的Id（Who）在通过了怎样的鉴权（How）

之后，就允许进行那些操作（What）：Who How What；permission（What）就是一个int表示的位码，每一

位代表一个对应操作的允许状态。类似unix的文件权限，不同的是共有5种操作：CREATE、READ、WRITE、

DELETE、ADMIN(对应更改ACL的权限)；Id由scheme（Who）和一个具体的字符串鉴权表达式id(How)构成，用

来描述哪个/哪些范围的Id应该怎样被鉴权。Scheme事实上是所使用的鉴权插件的标识。id的具体格式和语

义由scheme对应的鉴权实现决定。
　　

　　1、在zookeeperC的API里面，设置ACL的时候需要传入一个类型为structACL的结构指针，structACL结构类
　　
　　型的定义如下：
　　structACL_vector {
　　int32_t count;
　　struct ACL *data;
　　};
　　可以看出，该结构包含两个字段：一个用于记录结构中ACL结构个数的，另一个应该是一个指向ACL结构数组
　　
　　的指针（数组长度就由count决定了），ACL结构的定义如下：
　　struct ACL {
　　int32_tperms;
　　struct Idid;
　　};
　　这个结构也是两个字段：perms的意思就是permission，记录着权限，权限值从0到31说白了就是五个bit位
　　
　　分别记录五种权限，从高位到低位分别是admin、delete、create、write、read，简称adcwr，权限的具体
　　
　　含义不解释。另一个字段又是一个结构Id，（要处理这么样一个结构果断提防内存泄露）该结构的定义如下
　　
　　：
　　struct Id {
　　char *scheme;
　　char * id;
　　};
　　到这里算是清楚了，里面两个字段：scheme标志着权限管理策略，目前有四个：world、auth、digest和ip
　　
　　，具体不解释。Id字段是真正用来做权限匹配的，匹配成功就算你拥有权限。
　　整个结构综合业务那边解释的很清楚了，就不在说了，只是把具体定义给大家看看，说白了，如果要设置权
　　
　　限，就要弄这么样一个结构出来，把需要的字段都填好，还要填对（比如如果scheme是“digest”的话，id
　　
　　必须具有“user：password”的格式）。
　　2、可以设置节点权限的API主要有两个，一个是create，一个是setACL，前者是在创建的时候就设置了，后
　　
　　者是另行设置，直观上来讲，后者设置能不能成功那都是不一定的，因为起码你要有a权限的。其实，前者
　　
　　也不好说了，经典反例请看综合业务博客，不解释。
　　3、每个节点在创建的时候肯定要设置一个权限的，最经常设置的就是ZOO_OPEN_ACL_UNSAFE，也就是说
　　
　　adcwr= 31、scheme = “world”、 id = “anyone”。简单地说：随便哪个家伙，想干什么都行。根据综
　　
　　合业务博客，在一个zookeeper session创建以后会为该session创建默认的Id，其中scheme= “ip”、 id
　　
　　就是客户端的IP地址，在访问节点的时候，zookeeper内部会将这个权限信息附加在消息中发送，消息在处
　　
　　理的时候会将消息中的Id信息与节点的ACL信息进行匹配，对于ZOO_OPEN_ACL_UNSAFE权限的节点，任何匹配
　　
　　都会是成功的。
　　4、除了在session创建时默认构造的Id，客户还可以指定自己的权限，这需要用到zoo_add_auth函数，该函
　　
　　数就是用来重新声明自己的Id。比如，如果客户端要访问一个节点时发现权限不够，如果它知道节点的权限
　　
　　设置，它就可以重新设置自己的Id，并达到访问节点的目的。
　　5、当scheme为“digest”的时候，id字段必须具有“user：password”的格式，当我们调用zoo_add_auth
　　
　　函数时，password代表的字符串会经过SHA1加密。而调用getACL函数时我们看到的password字段代表的字符
　　
　　串已经是加密后的字符串了。因此“digest”策略下，在调用setACL时，password部分的字符串必须是密文
　　
　　，而调用zoo_add_auth函数password部分的字符串必须是明文。
　　用最简单的话总结，创建节点的时候会分配权限和验证Id，用户可以通过zoo_add_auth函数设置自己的验证
　　
　　Id，同时用户可以通过setACL重设权限和验证Id，如果验证成功用户将拥有该节点赋予该验证Id的权限。