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

Re: (ITS#6943) segfault in rwmmap in 2.4.25



In regard to: Re: (ITS#6943) segfault in rwmmap in 2.4.25, Pierangelo...:

>> At the time of the search, the very last thing that was logged was
>> 
>> May 17 17:03:03 server2 slapd[5168]: conn=28588 op=3 SRCH
>> base="cn=groups,dc=ndsu,dc=nodak,dc=edu" scope=2 deref=0
>> filter="(&(?objectClass=posixGroup)(?objectClass=apple-group)(objectClass=extensibleObject)(|(?apple-group-nestedgroup=ABCDEFAB-CDEF-ABCD-EFAB-CDEF0000001B)))"
>> 
>> May 17 17:03:03 server2 slapd[5168]: conn=28588 op=3 SRCH attr=cn
>> apple-generateduid gidNumber apple-group-realname ttl sambaSID rid
>> primaryGroupID apple-keyword apple-group-nestedgroup
>> 
>> 
>> I'll happily provide any details that I've mistakenly left out or that would 
>> aid
>> in debugging the issue.
>> 
>> The issue certainly could be caused by an error in my rwmRewriteRule, but I
>> imagine that slapd shouldn't segfault even if my rwmRewriteRule is wrong.
>
> Yes (I believe), and yes.  I believe the mapping is being applied to an 
> attribute that is not explicitly defined in the schema, but rather proxied or 
> somehow treated as undefined.  For this reason, the matching rule pointer is 
> NULL.  Can you check the definition of "apple-group-nestedgroup", if any?  Of 
> course, slapo-rwm should not crash on something like this.

Thank you Pierangelo.

We don't have any definition for apple-group-nestedgroup in any of the
schemas that I have loaded.  It's not something we support.  We're also
not doing any proxying.  Note also that the search base it's using
(cn=groups,dc=ndsu,dc=nodak,dc=edu) isn't valid.  So, it's some Apple
system on campus that someone has set up to query our LDAP tree, looking
for things that the Mac OS X expects to find, but that we don't have or
support.

One thing that confuses me a little -- I set the rwm-rewriteContext to
"bindDN", which I perhaps incorrectly believed meant that rewriting would
only be done for authenticated binds (i.e. not anonymous binds), and
this client did not authenticate.  I was under the mistaken impression that
rwm shouldn't even be called in cases like this.  I don't (currently) need to
rewrite searches or results from searches, only the bind credentials, for
when we eventually enable support for ldap authentication.

Does that answer your question?  Would it be helpful to see either my
original slapd.conf or the slapd-config that results from the conversion?

Thanks much,

Tim