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

[Enrik Berkhan]

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