Architcecture for winbindd client character conversion.

[Jeremy Allison]

On Tue, Aug 28, 2007 at 10:36:18AM +0200, Björn Jacke wrote:
> 
> that means a winbind client running in legacy en_US locale will for 
> example see a iso8859-1 encoded user name "domänen administrator" while 
> at the same time a 'getent passwd "domänen administrator"' on the 
> same system gives *nothing*. That will be because libc will not do any 
> conversion and IIRC the correcponding nsswitch functions do not care 
> about locales at all. Instead the same user via nsswitch will have a 
> "totally different" name: "domänen administrator" - which is again 
> not known by a "localized" winbind.
> 
> Am I wrong? Otherwise I'm not so convinced that such a conversion 
> is a good idea.

Yes you're wrong. Right now a winbind client running in legacy en_US
locale when querying winbindd will not be able to see any names with
characters > 127 in ISO8859-1 that exist on the DC.

Of course libc doesn't do the conversion, and neither does nss. That's 
the point. winbindd needs to know what the incoming charset is from
the client and convert into the "unix charset" in smb.conf on read,
and convert back into the client charset on returning strings to
the client. So a winbind client running in legacy en_US locale
talking to a fixed winbindd will correctly see :

getent passwd "domänen administrator

because it's talking to a winbindd that does the ISO8859-1 <-> unix
charset <-> UCS2-LE -> Windows (or Samba) DC conversions correctly.

That way the client only ever sees strings in it's own locale
charset, and winbindd copes with the conversion. It's the same
way we cannonicalize filenames when reading/writing to the disk
by converting from the charset sent be the client (either UCS2-LE
or DOS charset in the smb client case).

Expecting every client to load in iconv and do the conversion for
every string is not reasonable.

I don't think you understand how broken we currently are for
users not using utf8 locales and charsets (that means most
of Japan btw :-).

Jeremy.