[PATCH] central range check for sids2xids

[Michael Adam]

On 2016-08-10 at 11:18 +0200, Volker Lendecke wrote:
> On Wed, Aug 10, 2016 at 10:23:29AM +0200, Michael Adam wrote:
> > 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'd have to look in detail, but yes, that would be a possible
> approach. We have to take care for tdb, which might allocate id's, and
> for which a check in the parent might be too late. But hash, ad
> and rfc2307 don't have their own databases and just returning things
> readonly should be kept as simple as possible IMO.
> 
> > 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?
> 
> Yes. Add the idmap distinction between gencache, frontend and backend
> into the mix and you're fully lost.

:-)

> That's why I want things just as simple as possible.

Makes sense! I will try to rule out the error with the rodc test
env and revert with updated patches...

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/a16a0f22/signature.sig>