Hi, Alan DeKok wrote:
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.
The LDAP-escaping is ok, AFAICS. The octal escapes from librad_safeprint() are the problem. That's what I meant by 'destroyed', bad wording maybe.
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.
Ok, so how should this be gone about? Change librad_safeprint() to allow 8bit or UTF-8 only? Change vp_prints_value() to use something else than librad_safeprint()? I don't know because I can't oversee the possible side effects. I don't want to make things worse :) Enrik