Managing DNs in libads only in utf8

Gerald (Jerry) Carter jerry at
Tue Feb 27 16:11:22 GMT 2007

Hash: SHA1


> Attached patch should work, 

This statement is a little disconcerting.  The "should"
implies that you haven't tested it.  Maybe you have
and this is just a syntax error.

Why should we review and potentially debug a patch for a
bug that may not be fixed?  I'm know that I may see a little
stubborn here but reviewing untested patches is not an
efficient use of code review.

> however if we decide to go the struct {} way, this patch
> is not so important (as I said I compiled it but not
> tested it as I wanted input before committing myself too 
> much for something that could be rejected).

I agree with Volker.  Any patch that cannot enforce the
type checking for UTF-8 strings and cacth a mismatch
with a char* is bound to get us in trouble.   We need
to be able to look at the code for single function and
know what we are dealing with.

If that makes this patch obsolete, then we should just
move forward with the struct design IMO.  And coding in small
chunks (like patches submitted to lkml) will really help
when review the bzr tree.

>> I still need an example of how to reproduce the original
>> bug before I can review this.
> Easiest way:
> Set unix charset = ASCII
> Create an AD user with a non ASCII character in the
> DN (you can keep the pre-Windows2000 name ASCII that
> doesn't matter).  Add that user to a group.
> The user will not be reported as member of that group
> by nss_winbind because the utf8->ASCII->utf8 conversion
> alters the DN.
> Change the DN back to be ASCII and as soon as
> the winbindd cache expires the user magically appears
> back as member of the group.

Can you point me at which method in winbindd_ads.c
is the culprit?  I know about libads.  But I want to trace
one winbind call.

cheers, jerry

Version: GnuPG v1.4.2.2 (Darwin)
Comment: Using GnuPG with Mozilla -


More information about the samba-technical mailing list