Architcecture for winbindd client character conversion.

[simo]

On Tue, 2007-08-28 at 12:22 -0700, Jeremy Allison wrote: 
> On Tue, Aug 28, 2007 at 03:03:49PM -0400, simo wrote:
> > 
> > Locale is something that is meant to be set per system, not per session,
> > the fact that you can do insane things like changing the session locale
> > so that it is different from the system locale does not mean we have to
> > help it.
> 
> Fundemental disagreement is here.

Yes, definitely

> Locale's can be changed between nss
> calls.

Yes and if you do that you are on your own, the system will not help you
if you create a file name in utf8 and then try to open it using the
iso8859-15 representation of the same file name. It gives you back just
ENOTFOUND

> We might not like it but we must support it.

This is were we disagree, I may not like the fact that glibc allows
someone to do insane things like changing the locale per session, and I
don't, but there was probably no other easy way to do it in glibc.
That does not mean we have to make our code broken :-)


> > I may claim as well that, as you are using a broken distribution, your
> > opinion is flawed, but I don't do that cause I don't think you are
> > stupid and I don't want to piss you off.
> 
> That's ok, I've been called worse :-). I just think you're really
> wrong on this that's all :-).

And I think you are totally wrong :-)

> > I would agree with, and even welcome, a patch to implement unix charset
> > = auto and use that by default and determine at daemon startup what is
> > the current system locale. That would be a good patch and a better
> > default.
> > Cluttering winbindd code instead would be not IMO.
> 
> No, this is the wrong solution. I don't understand your
> objection. It's a clear bug, and this change is not different
> from rpcstr_push()/rpcstr_pull(). Do *these* calls clutter
> the code ? If not, why these are ok and not a similar
> wb_clientstr_push()/wb_clientstr_pull() ?

I will try one last time.

Let's try with a simple example so that we can start reasoning around
something real not just words.

Now let's assume I have a system where you have a user called: ABCìèÖÄ
This name can't be represented in iso8859-1

Q1: how would your patch address that?

Now let's assume you are instead using iso8859-15 that will let you
translate these characters (Just to not truncate the discussion from
start).

So you have user ABCìèÖÄ with system locale utf8.en_US and his home
is /home/ABCìèÖÄ, you support locale changes in nss so now the user
changes the locale to iso8859-15 and does a login which does one or many
getpwnam() calls:
you get back (#### means converted to iso8859-15 **):
ABC####:xxx:xxx:foo bar:/home/ABC####:/bin/sh

Now if you try to access the home directory you simply fail because the
home directory on the filesystem is:
/home/ABCìèÖÄ not /home/ABC####

Note that a user with a regular name like jeremy which has the home
in /home/èÖ/jeremy would face a problem *with* your patch and none
without (suppose èÖ is the domain your user is in).

Q2: So what do you get supporting multiple locales at login? Do you need
to find a way to fix the bug about file names being in a different
locale as well ?

Well, perhaps you can log in, if your locale have translatable
characters, but then, at best, you are stranded in /tmp or at worst pam
will deny you to login because you don't have a home directory.

Even if by luck your login name uses just 7bit ASCII chars and therefore
your home directory is ok, you will start experiencing problems trying
to access files you previously created when the locale was utf8 or files
other have created with other locales.

Q3: Have you read my counter proposal about unix charset = auto ? Why
that is not ok for you?

Can you please answer Q1,Q2,Q3 ?

Simo.


** I tried to use iconv and copy and past the actually converted
characters but this simply made evolution (on Ubuntu with utf8 locale)
go mad eat all memory and put the machine in a swap-frenzy state so deep
that after 10 min. I decided to do a cold restart :-/
This is a clear indication that mixing locales is baaaadd :-P

-- 
Simo Sorce
Samba Team GPL Compliance Officer
email: idra at samba.org
http://samba.org