As far as I understand the log - you need to include the port. This should help then:
by peername.regex="IP=10.16.13.8[1-6]:[0-9]*" read
Regards, Michal
On 05/07/07, Brian Gaber Brian.Gaber@pwgsc.gc.ca wrote:
Tried your suggestion and still have a problem.
Here is the new slapd.conf:
access to * by self write by peername.ip=10.16.13.84 write by peername.regex="IP=10.16.13.8[1-6]" read
Here is the log:
entry_decode: "SFTid=0001-00000000,ou=servers,o=sft" Jul 5 10:46:35 ias2 slapd[11401]: <= entry_decode(SFTid=0001-00000000,ou=servers,o=sft) Jul 5 10:46:35 ias2 slapd[11401]: => bdb_dn2id("SFTid=0001-00000000,ou=servers,o=sft") Jul 5 10:46:35 ias2 slapd[11401]: <= bdb_dn2id: got id=0x0000002f Jul 5 10:46:35 ias2 slapd[11401]: => test_filter Jul 5 10:46:35 ias2 slapd[11401]: EQUALITY Jul 5 10:46:35 ias2 slapd[11401]: => access_allowed: search access to "SFTid=0001-00000000,ou=servers,o=sft" "SFTid" requested Jul 5 10:46:35 ias2 slapd[11401]: => acl_get: [1] attr SFTid Jul 5 10:46:35 ias2 slapd[11401]: => acl_mask: access to entry "SFTid=0001-00000000,ou=servers,o=sft", attr "SFTid" requested Jul 5 10:46:35 ias2 slapd[11401]: => acl_mask: to value by "", (=0) Jul 5 10:46:35 ias2 slapd[11401]: <= check a_dn_pat: self Jul 5 10:46:35 ias2 slapd[11401]: <= check a_peername_path: 10.16.13.84 Jul 5 10:46:35 ias2 slapd[11401]: <= check a_peername_path: IP=10.16.13.8[1-6] Jul 5 10:46:35 ias2 slapd[11401]: => acl_string_expand: pattern: IP=10.16.13.8[1-6] Jul 5 10:46:35 ias2 slapd[11401]: => acl_string_expand: expanded: IP=10.16.13.8[1-6] Jul 5 10:46:35 ias2 slapd[11401]: => regex_matches: string:^I IP=127.0.0.1:46504 Jul 5 10:46:35 ias2 slapd[11401]: => regex_matches: rc: 1 no matches Jul 5 10:46:35 ias2 slapd[11401]: <= acl_mask: no more <who> clauses, returning =0 (stop) Jul 5 10:46:35 ias2 slapd[11401]: => access_allowed: search access denied by =0 Jul 5 10:46:35 ias2 slapd[11401]: <= test_filter 50
-----Original Message----- From: Michal Dobroczynski [mailto:michal.dobroczynski@gmail.com] Sent: Thursday, July 05, 2007 10:36 AM To: Brian Gaber Cc: openldap-software@openldap.org Subject: Re: Challenge With Access Control
On 05/07/07, Brian Gaber Brian.Gaber@pwgsc.gc.ca wrote:
Hope someone can explain this to me. I am sure it is very trivial. I
have a primary LDAP server (10.16.13.84), a replica LDAP server (10.16.13.85) and a few clients all with a 10.16.13.x address.
Here is the access control I thought would work:
access to * by self write by peername=10.16.13.84 write by peername=10.16.13.81 read by peername=10.16.13.82 read by peername=10.16.13.83 read by peername=10.16.13.85 read by peername=10.16.13.86 read
Here is what does work:
access to * by self write by peername.ip=10.16.13.84 write by * read
By work I mean that when I am on the replica (10.16.13.85) andissue an ldapsearch to itself I get a 32 no such object with the top access, but I get the expected result with the bottom access.
I am not 100% sure, but maybe this will help you (I am using similar ACL). AFAIR in the peername you need to add the "IP=" - but I don't really remember, please correct me. The regex matching directive that works for me looks like this:
by peername.regex="IP=10.10.120..+" read
Then you could try:
by peername.regex="IP=10.16.13.8[1-6]" read
And please double check if you need to supply the "IP=10.10.10.10" for the "by peername" without regex. The regex solution will not conflict with the first entry as write permission includes reading (and ACL parsing stops on the first matched rule).
Hope this helps.
Regards, Michal
Brian Gaber