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

[Gerald (Jerry) Carter]

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.
> 


-- 
=====================================================================
Samba                                    ------- http://www.samba.org
Centeris                         -----------  http://www.centeris.com
"What man is a man who does not make the world better?"      --Balian