[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: peername + openldap 2.2.4
>
>
> --On Wednesday, January 07, 2004 8:12 PM +0100 Pierangelo Masarati
> <ando@sys-net.it> 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 139.184.0.0/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
>>> (ITS#2904).
>>
>> Works perfectly for me (HEAD, but right now it's exactly
>> like 2.2.*). I note that
>>
>> peername="139.184.*.*"
>>
>> 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.
>>
>> Try
>>
>> peername.regex="139\.184"
>>
>> this will surprisingly match the IP you're using.
>> A rather better solution would be to use
>>
>> peername.regex="^IP=139\.184\.*"
>>
>> 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
>> client.
>
> I used:
>
> peername="127.0.0.1"
>
> 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
peername.ip="127.0.0.1"
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
peername.subtree="139.184"
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
> denied.
See above ...
p.
--
Pierangelo Masarati
mailto:pierangelo.masarati@sys-net.it