还是关于 openldap 的 ACL ， 案例求解

alvis

需求如下，在同一个 ldap 下建了两个 RootDSE，

suffix          "ou=system"
suffix          "dc=example.com"

ou=system 准备用来做 系统认证，如 ftp 账号之类的
dc＝example.com 是给 example 公司建立的 LDAP 地址簿

比如 ldap 的目录树类似如下

ou=system
| - cn=root,ou=system
| - cn=readonly,ou=system
| - ou=users,ou=system
|     \ - cn=user 1,ou=users,ou=system
\ - ou=groups,ou=system
      \ - cn=group 1,ou=groups,ou=system

dc=example.com
| - cn=user 1,dc=exapmle.com
| - cn=user 2,dc=exapmle.com
\ - cn=admin 1,dc=exapmle.com

现在想写的 ACL 要完成以下功能

1. cn=root,ou=system 作为 ou=system 和 dc=example.com 的 rootdn

2. cn=readonly,ou=system 只能读 ou=system 和 dc=example.com 下的 dn，但不能进行修改

3. ou=users,ou=system 下的 dn 只能读取及修改自己的 dn

4. dc=example.com 下的 dn 只能读取 dc=example.com 下 dn ，不能读取 ou＝system 下的 dn
且可对自己 dn 进行修改

5. cn=admin 1,dc=exapmle.com 可对 dc=example.com 下 dn 进行修改


嘿嘿，大家共同研究研究

alvis

access to dn.base=""
        by dn.sub="ou=system" read
        by dn.sub="dc=example.com" read

access to dn.base="cn=Subschema"
        by dn.sub="ou=system" read
        by dn.sub="dc=example.com" read

access to dn.sub="ou=system"
        by self write
        by dn.base="cn=root,ou=system" write
        by dn.sub="ou=system" read
        by anonymous auth

access to dn.sub="dc=example.com"
        by self write
        by dn.base="cn=root,ou=system" write
        by dn.base="cn=admin 1,dc=exapmle.com" write
        by dn.base="cn=reaonly,ou=system" read
        by dn.sub="dc=example.com" read
        by anonymous auth

[根据 七楼 的提示修改版]
access to dn.base="" by * read
access to dn.base="cn=Subschema" by * read

access to dn.sub="ou=system"
        by self write
        by * none break

access to dn.sub="dc=example.com"
        by dn.base="cn=admin 1,dc=exapmle.com" write
        by self write
        by dn.sub="dc=example.com" read
        by * none break

access to *
        by dn.base="cn=root,ou=system" write
        by dn.base="cn=reaonly,ou=system" read
        by anonymous auth



头两个 access 说实话，我也不明白 dn.base="" 和 dn.base="cn=Subschema" 的作用，感觉
有点想是否允许 show RootDSE ，还烦请哪位明白人不吝赐教

[ 本帖最后由 alvis 于 2007-7-4 14:31 编辑 ]

py

一般情况下是这样写的
access to dn.base="" by * read
access to dn.base="cn=Subschema" by * read
这样做是为了让客户端能读取RootDSE，以便今后操作。
你上面的例子限定在了“dn.sub”，这应该是不让匿名用户读取RootDSE的信息。

ACL的问题是最好也是最难解决的，因为它没有标准化，即使是openldap，不同版本之间ACL也有区别。但也容易解决，一试不就知道了。我现在手边没有测试环境了，只能搂住自己测试看看了。

alvis

嗯，现在 openldap 的 ACL  中主要有几点困惑
一、
好像在开始建立目录时，会自动建立 cn=config 和 cn＝subSchema 两个目录，
cn=config 好像是 2.3 新加的，是 slapd.conf 的 ldap 嵌入 （好像是这么个，还望达人指教）
cn=subSchema 的作用一直没明白，好像是 RFC 里就规定了（也望达人指教）

二、
就是在前后 access to 处理上的覆盖规则上
把规则模型简化为 access to <what> by who
现在感觉是，如果之前的某句中 what 已经匹配某 entry，那么这个 entry 的权限就由这个子句决定了，
后面的即便再有对包含同一 entry 的其它权限定义，也无法被通过。

很想找到怎么来控制权限覆盖规则的方法，能让后面新定的规则添加到已有的规则队列（不知道我表述清楚没）

py

1. cn=config的确是2.3新加入的，包括的功能非常丰富，我现在只用了很少的一点，在cn=config这颗独立的树上可以存放很多信息，例如配置文件slapd.conf的设置，ACL部分开始的时候不能即时生效，现在已经可以了。但我没试过，我还是都用slapd.conf存呢。
cn=subSchema在很多的LDAP产品中都有定义，我已经不记得是否在RFC中看到过了，但应该是被定义为标准的。cn=subSchema的作用很简单，就是存储RootDSE信息，拿OpenLDAP来说，这里存取了所有OpenLDAP支持的操作。举个例子，客户端在操纵OpenLDAP的时候，如果能知道server端是否支持一些排序规则的话就可以更简单的对搜索结果进行排序，而不用把搜索结果再遍历一边了。而这些server端能够支持的排序规则就被写在RootDSE中，还有诸如很多的操作，没一个操作都有一个标准的OID与之对应。
2. OpenLDAP目前的ACL是顺序优先的，这个除非去修改源码，不然应该是不能被改变的。
也就是说，如果你在最开始写上了
access to * by * write
那之后的所有权限控制也就枉然了。

alvis

谢谢达人指教

hyorke

ACL的规律覆盖是可以实现的。一般的ACL的定义是access to <what> [ by <who> <accesslevel> <control> ]。其中的control部分可以取三个值stop, continue和break。
stop：一旦匹配到就立刻停止，如果没有设置control这就是缺省值。
continue：匹配上之后继续处理同一个access语句中的其他的<who>，这就可能导致已经匹配上的<who>的<accesslevel>发生变化，即后面的<who>覆盖前面的
break：继续处理以后的access语句。使用break就可以用后面的access覆盖前面的

alvis

哈，感谢，总算明白那个 该死 的 by * none break 的含义了

能覆盖就好多了，还是习惯以 who 来作为基准定规则

[ 本帖最后由 alvis 于 2007-7-4 14:35 编辑 ]

py

stop, continue和break, 完全没用过，有时间一定好好研究下

alvis

現在看著 openldap 的 ACL 終于不頭疼了，原來一直都是這個 control 在搞怪