[turba] Special character handling bug in LDAP addressbooks

[Scott Courtney]

Here's another bug that's a little more subtle, and for which I don't have a
very good recommended fix.

If you create an addressbook entry that's stored in LDAP, the distinguished
name (DN) is of this form:

cn=_nickname_, ou=_owner_uid_, ou=personal_addressbook, dc=example, dc=com

where _nickname_ is the name by which the addressbook entry is stored (the
common name of the recipient) and _owner_uid_ is the user who owns this address
book. (In our schema, it's "uid" but it could also be "mail" or "cn" depending
on how one has set up the LDAP schema.)

Now, suppose user "jane_smith" creates an addressbook entry like this:

    Name:   John Doe (Work)
    Email:  j_doe at example.com

It will be stored in LDAP with a DN that looks like this:

cn=John Doe (Work, ou=jane_smith, ou=personal_addressbook, dc=example, dc=com

Notice how the trailing parenthesis is dropped from the "cn"? This corruption
also happens within the "cn" attribute, not just the DN. Now, I can change it
in the "cn" attribute by using the Turba web interface to edit the field,
dropping the "(Work)" part. But OpenLDAP (and probably some other LDAP servers)
will not actually allow you to change the DN of an existing entry. So this
bogus DN remains forever unless the user can figure out how to delete and
re-create the entry properly.

It's clear that some kind of special-character filtering or escaping is
needed on the nickname to make it work properly in LDAP. I'm not sure what
other characters might have similar problems. I don't have a good suggestion
of what to do here, but I thought someone else might have a suggestion.

I realize that I can work around this by storing the addressbooks as Horde
preferences rather than direct LDAP entries, but this is a *very* large
scale installation (several hundred thousand users) and I'm concerned about
the effeciency of that approach. The Horde preferences (with which I
experimented earlier in the project) appear to Base64 encode the entire
addressbook, storing it as an attribute value and not with its own DN. That
sidesteps this character escape issue, but at the expense of efficiency.

Anyone have any suggestions here? Am I overrating the efficiency argument?

Kind regards,

Scott

-- 
-----------------------+------------------------------------------------------
Scott Courtney         | "I don't mind Microsoft making money. I mind them
courtney at 4th.com       | having a bad operating system."    -- Linus Torvalds
http://4th.com/        | ("The Rebel Code," NY Times, 21 February 1999)
                       | PGP Public Key at http://4th.com/keys/courtney.pubkey