[PATCHES] Fix userParameters once and for all
Stefan (metze) Metzmacher
metze at samba.org
Mon Jun 30 10:47:47 MDT 2014
Am 30.06.2014 00:07, schrieb Andrew Bartlett:
> On Sun, 2014-06-29 at 23:57 +0200, Stefan (metze) Metzmacher wrote:
>> Hi Andrew,
>>>>> This patch series tries to fix the userParameters issue once and for all
>>>>> rather than just papering over it by increasing the malloc buffer.
>>>>> This ensures that Samba stores the userParameters array in the same
>>>>> way the windows client uses it, as a 'UTF-16-LE' buffer (sort of, the
>>>>> data is not actually unicode).
>>>>> The only thing not done in this patch set is to have our LDAP server
>>>>> convert on output, but Microsoft assures us that this can not be
>>>>> relied on anyway, as the data is not UTF8 nor can it be transformed to
>>>>> UTF8 with certainty.
>>>>> Please review and push.
>>>> I'll have a look at it next week...
>>> Any thoughts?
>> I really would like to implement this like windows and provide
>> the utf8 view over LDAP. Otherwise it's not "once and for all".
> Perhaps, but this is still a necessary and required condition for this,
> and as far as I propose to go at this time.
> We already store and return this value over SAMR 'as is', and if we
> don't merge these patches, we have memory corruption as Univention saw.
>> A while ago I started a test check the LDAP/SAMR interaction.
>> It isn't just a start and we need to extend it to also check DRSUAPI.
>> Once we have tests which demonstrate the real bahavior we might decide
>> to leave out some features.
>> Do we have real world examples where the userParameters field is set to
>> values which can't be represented by utf8 in a lossless fashion?
> We have the very strong assurance from Microsoft's engineers that this
> value is not safely represented as UTF8.
> I don't have anything more than this for now, but the work I've done is,
> in my view, a required pre-condition to further work here. Leaving us
> with memory corruption bugs or returning 'UTF8' data over SAMR is not an
> acceptable state of affairs.
> None of this stops you doing further work on this, but as neither of us
> got any further than this in the 6 months we have known about this
> issue, leaving it totally broken for Samba 4.2 isn't an option.
> Therefore, I would request that we merge my changes, and that then you
> build on top of that work when you have the time.
Ok, I'll think about it for a few days. Please ping me again if
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 246 bytes
Desc: OpenPGP digital signature
More information about the samba-technical