[LDAP-interop] native solaris 8 client and openldap 2.2: "requirebind" / acls

[Pierangelo Masarati]

Tay, Gary wrote:

>It seems like Andy has not applied the "result.c" patch required to properly read RootDSE.
>  
>
^^^ this is a horrible hack!  A "cleaner" solution would be to design a 
dynamic module that intercepts searches and, if the base is "" and the 
scope is base and the attribute list is empty or contains "*", it 
injects a '+'.  This would avoid to patch slapd and make it not 
compliant to a number of specs.  This can work with OpenLDAP >= 2.3.  
Stay tuned.

> 
>===
>I'm seeing a few issues here.
>1) rule 3: <access to dn="ou=People,..."> in OpenLDAP 2.2 means access
>to that entry only; if you meant subtree access, you should rather use
><access to dn.subtree="ou=People,...">.
>2) rule 3: <by users auth> means that already authenticated clients can
>only access this entry for... authentication; makes little sense to me.
>3) rule 3: <by anonymous read> means that non-authenticated clients can
>read what authenticated clients could not.
>4) rule 4: maybe you were misguided by this catchall, which was caught
>buy anything but "ou=People,dc=example,dc=com"?
>===
>I wrote the how-to, thank you Pierangelo for correcting my ACLs.
> 
>Do the following ACLs make sense? What I want is NOT FOR "anonymous" user to read anything under the ou=People, but FOR authenticated users and proxyAgent to do so.
> 
>access to attrs=userPassword
>            by self write
>            by * auth
>access to dn=""
>            by * read
>access to dn.subtree="ou=People,dc=example,dc=com"
>            by self write
>            by dn="cn=proxyagent,ou=profile,dc=example,dc=com" read
>            by users read
>            by anonymous none
>access to * by self write
>            by * read
>  
>
Of course it depends on what you intend to do.  The above look like a 
minimal generally useful set of ACLs that allow everyone to perform 
simple bind (auth access to all userPasswords in the DSA), read access 
to the rootDSE (I'd add read access to "cn=Subschema" just in case; 
actually, I note it's already there in the HOWTO).
The culprit is in rules #3 & #4. where entries under "ou=People" can:
  - be written by themselves (isn't this too liberal?)
  - be read by some applicative identity
  - be read by all authenticated clients
  - the last who "by anonymouys none" is redundant, you can safely 
remove it (I see in the HOWTO that you allow to choose between "by 
anonymous {none|auth|read}").
and all other entries can:
  - be written by themselves (see above)
  - be read by everybody (this catches the "cn=Subschema" anyway; it's 
fine unless you prefer to specifically address it with a rule, so that 
in case this catchall is modified to have "by * <(less than read)>", 
"cn=Subschema" is still readable.

If you realize the above, and it complies with your intentions, then 
they look definitely fine.  I'd post a comment like the above along with 
the rules, so that people that use them can judhe if they fit their 
needs and have a hint as where and how modify them if they don't.

p.


    SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497

_______________________________________________
LDAP-interop mailing list
LDAP-interop at fini.net
http://lists.fini.net/mailman/listinfo/ldap-interop