[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