[PATCH] central range check for sids2xids

Michael Adam obnox at samba.org
Wed Aug 10 08:23:29 UTC 2016


On 2016-08-10 at 09:47 +0200, Volker Lendecke wrote:
> On Tue, Aug 09, 2016 at 06:39:36PM +0200, Michael Adam wrote:
> > The attached patch introduces a central range check
> > for the unix ids produced by the id mapping backends
> > (sids2xids).
> > 
> > I noticed that some backends (at least ad and hash),
> > have no range check any more. This is dangerous
> > because it can lead to ids leaking out of id-mapping
> > that are from ranges that this backend is not
> > responsible for the backward mapping xids2sids
> > would then lead to a different sid than the one
> > started with.
> > 
> > Instead of adding this to all backends, here is
> > a patch that adds the check to the central
> > winbind code.
> > 
> > Opinions?
> 
> Can we do all of that in the parent? Keep the children as simple as
> possible?

I'll try to do a different patch, I need to see
why the wbinfo(rodc:local) test is failing now
anyways...

Then we should probably remove all such range checks
(everything that can be done centrally, in the parent)
from the idmap backends as well, right?

I have to admit that whenever I look at these levels of the code,
I always have a hard time understanding what the parent / child
layout of the code files is. It's not very explicit for the
casual contributor. So I originally thought that my code changed
the highest level. But now I (seem to) hav understood (again) that
the wb_....c files are the actual parent top level code, the
implementation of the wbc 'protocol', correct?

winbindd_dual.c seems to be the code that establishes the actual
parent-child communication. And winbind_dual_srv.c is the code
in the child that implements that actual tasks in the servers?
Called by the idl-generated server stubs. And apparently, the
idl-generated client calls are called directly from the
wb_foobar.c files. Is that roughly correct?

Thanks - Michael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20160810/41cc1d23/signature.sig>


More information about the samba-technical mailing list