Problem with expansion of %{Ldap-UserDn} containing UTF-8 (cf. Bug #411)

[Alan DeKok]

Enrik Berkhan wrote:
> Assume now the first search returns a user_dn containing UTF-8. The
> %{Ldap-UserDn} in the groupmembership_filter will then be expanded by
> xlat.c using \ooo (octal) for the 8bit characters. Then, the second
> search can not match, because the member attribute of the group contains
> member DNs in UTF-8, but the value to compare has been 'destroyed' by xlat.

  What part of the server has destroyed that?  The ldap escaping
function implements the requirements of RFC 4514 for escaping LDAP
strings.  It doesn't mangle UTF-8 strings.

> 1. How can this issue be solved for Ldap-UserDn? Or does a solution
> already exists that I have overlooked?

  I think the solution is to update src/lib/print.c to handle UTF-8 by
default.

> 2. Is this a general issue for variable expansions handling _all_ 8bit
> characters as kind of 'non-printable', may be 'unsafe' characters?
> Remember that most query expansions like in rlm_ldap and rlm_sql have
> their own notion of unsafe characters and escape again ...

  I think so, yes.

  Alan DeKok.