[PATCHES] Fix userParameters once and for all

Andrew Bartlett abartlet at samba.org
Sun Jun 29 16:07:16 MDT 2014


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.
> https://git.samba.org/?p=metze/samba/wip.git;a=commitdiff;h=cc3aeb1fa904e58bb1e93ab0636048298a5f64e1
> 
> 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. 

Thanks,

Andrew Bartlett

-- 
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team  http://samba.org
Samba Developer, Catalyst IT          http://catalyst.net.nz/services/samba






More information about the samba-technical mailing list