[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: Challenge With Access Control



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) and

> issue 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