Require winbindd in 3.0.25? [was Re: New IDMAP backend proceedings]

simo idra at samba.org
Tue Nov 7 20:01:53 GMT 2006


Finally it was decided on IRC (#samba-technical) to keep the current
sid_to_uid() and sister functions in as legacy functions.

This means that for standalone samba servers winbindd is not required.

Simo.

On Tue, 2006-11-07 at 22:27 -0800, Gerald (Jerry) Carter wrote:
> Raising the visibility of this since we really have to
> make a decision here.
> 
> The crux of the argument is whether or not winbindd
> should become the trusted holder of all idmap information.
> 
> To summarize Simo's proposal:
> 
> * Move all logic regarding SID <-> uid/gid conversions
>    to winbindd and simple have smbd call winbind_sid_to_uid(),
>    etc...
> 
> * Maintain the SID <-> uid/gid cache in smbd for performance.
> 
> To refresh your memory on the initial idmap design from
> the 3.0.0 alpha days, the original idea was to have
> the database layer be the IDMAP provider and let smbd
> and winbindd dig into the tdb file directly.  This was removed
> prior to the 3.0.0 release.
> 
> Note that Jeremy and I have done similar things when
> trying to track down performance problems on the HP PSA.
> Having smbd dig into winbindd_idmap.tdb did not improve
> things as the real killer was relating to network
> activities.  Therefore I do not believe that using
> winbindd as the gatekeeper for idmap information to be
> a problem.
> 
> The pro is that is does provide a clean design
> 
> The con is that winbindd would become required as
> per Simo's proposal.
> 
> A compromise would be to include the existing
> sid_to_uid() fall back code much like we include
> domain_client_validate() for 'security = domain'.
> 
> 
> 
> 
> 
> 
> cheers, jerry
> 
> simo wrote:
> 
> > I've been working for the last week on the agreed IDMAP specification.
> > 
> > In this tree you can find the code I am working on:
> > http://people.samba.org/bzr/idra/SAMBA_3_0-IDMAP.bzr
> > 
> > Actually tested and working only with the tdb backend for allocation and
> > store, ldap backend has been ported but is incomplete and not tested,
> > other has not been ported yet. IDMAP has been moved under
> > source/nsswitch
> > 
> > During the process I had to make some decision about how and where the
> > code makes decisions regarding mappings.
> > 
> > I wanted to explore the idea of trying to keep the logic in one place.
> > In a place where it is not easy to tamper with from the "outside" so
> > that we can keep control over the process. I found the current way to
> > handle mappings (with decisions taken at all layers) not good and
> > problematic. Both from the pov of understanding what's going on and
> > debugging it. And from the pov of possible interference and mistakes in
> > using the interfaces at the wrong layer.
> > 
> > For that reason I moved all the logic from sid_to_*id and *id_to _sid
> > and winbindd_*id_to_*id into idmap itself.
> > I've done that by creating two new idmap backends: idmap_nss and
> > idmap_passdb that are loaded automatically by idmap.
> > 
> > idmap_passdb is used to query our own SAM for the local and builtin
> > domains and also for some special SIDs.
> > 
> > idmap_nss is used to query nss and is added only if "winbind trusted
> > domains only" is true.
> > 
> > Unix users and groups domains are also handled here.
> > 
> > The allocation is handled by a separate backend, and you can have only
> > one allocating backend per server, while mapping backends can be as many
> > as one per trusted domain if wanted.
> > 
> > 
> > While coding I came to the conclusion that keeping everything in idmap
> > makes a lot of sense and keeps everything under sight. Changing
> > something there has a clear meaning server-wide, it also makes actually
> > possible to take the best decision on how to map something as all
> > information is available in one single place.
> > 
> > Actually I had 2 options: move everything in lookup_sid.c (*id_to_*id
> > functions) or move everything into IDMAP. I choose the latter because
> > the former would left open access to mess with mappings by direct calls
> > to the winbindd_*id_to_*id calls. Moving everything to IDMAP instead
> > makes it possible to ensure better control and reduce the possibility of
> > errors in managing mappings.
> > 
> > At the moment the only way to access IDMAP is via winbindd. I think this
> > is also the best way to do it.
> > IDMAP itself works better if a single process runs it. IDMAP makes calls
> > to DCs to validate SIDs, and calls to external providers (ldap, ad, our
> > sam and in future I hope the unixinfo pipe). Making it accessible
> > directly by smbd would mean that each smbd process could potentially
> > open a single separate connection to each provider and DC and this is
> > certainly not desirable on big servers.
> > 
> > Now the only issue I can see with this approach is that smbd becomes
> > dependent on winbind even for standalone servers.
> > 
> > This is a thing we can handle.
> > As Volker has proposed before, I'd like to ask how people would feel if
> > we make winbindd being forked off by smbd, so that we can be sure a
> > winbindd instance is always running when smbd needs it.
> > 
> > If forking winbindd off of smbd is deemed not desirable we can easily
> > make smbd access directly idmap as a fallback but I'd rather not do this
> > if possible.
> > 
> > Comments are very welcome, the design is not fixed in stone and can be
> > easily changed.
> > My preference is to keep the logic in IDMAP, keep IDMAP accessible only
> > from winbind and make winbindd be forked out of smbd.
> > However, I am completely open to discuss each of these decisions and
> > eventually change the code if the majority so wish (all I ask is a clear
> > explanation of the reason eventually so that I can direct my efforts
> > with a clue).
> > 
> > Simo.
> > 
> 
> 
-- 
Simo Sorce
Samba Team GPL Compliance Officer
email: idra at samba.org
http://samba.org



More information about the samba-technical mailing list