mkd@cs.brown.edu wrote:

...

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 indefinitely.

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 details.

...

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.

p.