New IDMAP backend proceedings

[simo]

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