[Date Prev][Date Next]
Re: (ITS#6334) hang during ldapmodify
>> Does the offending value of memberUid correspond to something specially
>> related to the modify operation? E.g. to the identity that is
>> performing the modification, or is any other operation 'round when the
>> hang occurs?
> The memberUids in this example are completely fictitious, so they don't
> have any connection to the uids of real users. The thing I find
> particularly intriguing is that I can change whether or not the update
> is successful by simply adding or removing a single digit on the last
> memberUid. If the last memberUid is 7 characters long (i.e. t247800),
> the modification goes through fine. However, if the last memberUid is 8
> or more characters long (i.e. t2478000), then the operation hangs
If you could get a backtrace with symbols (e.g. using an unstripped
binary) we could see some useful information. Right now, the easiest
answer would be a (subtle) bug in the "sortvals" feature. You should be
able to check by removing that statement from your configuration. This
should not require to reload the database from LDIF.
>> Is your GSSAPI somehow related to LDAP?
> We use GSSAPI for write authorization. I sent a copy of our slapd.conf
> file a few messages back, that should show the appropriate configuration
>> Are credentials actually stored in the same slapd you're modifying?
> I'm not sure I understand the question. Yes, account information is
> stored in the slapd database I'm modifying, but not the specific entry
> I'm modifying. The actual authorization happens through GSSAPI, so
> authorization for write access is actually happening via kerberos. Does
> this answer your question?
The SASL/GSSAPI might result in performing lookups in slapd if
information about identities is stored in the directory. If it were the
case, slapd.conf would not tell, as this would result from some
configuration in the GSSAPI layer. Nevertheless, given the above
description of the symptoms, this seems to be unrelated.