[Date Prev][Date Next]
Re: peername + openldap 2.2.4
> --On Wednesday, January 07, 2004 8:12 PM +0100 Pierangelo Masarati
> <firstname.lastname@example.org> wrote:
>>> --On Wednesday, January 07, 2004 9:06 AM +0000 Dave Lewney
>>> <D.M.Lewney@sussex.ac.uk> wrote:
>>>> Trying to restrict access to Openldap server (v2.2.4 running under
>>>> Solaris 8) to 188.8.131.52/16 with this acl ...
>>>> access to *
>>>> by peername="139.184.*.*" read
>>>> by peername="IP=127\.0\.0\.1:*" read
>>>> by users ssf=112 tls_ssf=112 read
>>>> by * none
>>> Hello Dave,
>>> I see the same issue. I've filed an ITS at the OpenLDAP website
>> Works perfectly for me (HEAD, but right now it's exactly
>> like 2.2.*). I note that
>> is an invalid regex (or, at least, results in a different
>> behavior from what you likely expect). Moreover, the default
>> for unqualified acl patterns is now EXACT rather than REGEX.
>> this will surprisingly match the IP you're using.
>> A rather better solution would be to use
>> Note that EXACT perrname strings make no sense since
>> the port in most cases would be randomly picked by the OS.
>> A "peername.ip" style modifier could be interesting,
>> but a radically better solution would be to use a more
>> reliable ACL policy than on ebased on the IP of the
> I used:
> This works perfectly in OpenLDAP 2.1. It does not work at all in
> OpenLDAP 2.2.
because it is compared against "IP=127.0.0.1:<port>"
where <port> is generated by the OS. In this case
you'd need some
where the "IP=" and the ":<port>" portions get
stripped. Note that also some "children" and
"subtree" styles could be useful: in the above
reported case, an hypothetical
would do the trick without using regexp at all.
I recall this issue being discussed some time ago,
to no extent.
> And it is useful in some cases for local lookups that otherwise get
See above ...