Re: Support for Base64 encoded values

[Ricardo Padilha <rpadilha [at] drobo.com>]

Responses inlined.

On 15/06/17 18:16, "Arthur de Jong" <arthur@arthurdejong.org> wrote:
>The value 'jos\xe9' is indeed the ISO-8859-1 encoding of josé. A UTF-8
>encoding could be 'jos\xc3\xa9' ('jos\u00e9' in unicode) or
>'jose\xcc\x81' ('jose\u0301' in unicode) or maybe something else
>entirely.

I was using the same visual representation that samba uses in its log
files. What I’m seeing in the LDAP database is in fact \xc3\xc9.


>nslcd currently does bytewise comparison but I think so does slapd
>which does the bulk of the comparison (use ldapsearch command to
>confirm this).

Would you happen to know of the top of your head where these comparisons
take place? Would it be by any chance in the authentication path?


>In theory it could be possible to do unicode normalisation in nslcd
>before passing strings in search filters to LDAP (patches welcome) but
>it would likely not solve all the problems.

The biggest problem I see are passwords. If anyone uses unicode characters
in passwords they’re essentially out of luck, since no one in their right
mind would normalize passwords.

Wouldn’t the cleanest approach be to use unicode-aware string comparisons?
This way the original strings remain untouched.



> I expect there are multiple
>places in the NSS and PAM stacks that expect usernames to be a subset
>of 7-bit clean ASCII.

Strangely enough, it seems like /etc/passwd couldn’t care less. We’ve had
our current system running with unicode usernames for as long as I can
remember, and this has never been a problem until the introduction of PAM
and LDAP. :)


R.

-- 
To unsubscribe send an email to
nss-pam-ldapd-users-unsubscribe@lists.arthurdejong.org or see
https://lists.arthurdejong.org/nss-pam-ldapd-users/