yet another idmap rewrite - still for 3.6 ?

[Andrew Bartlett]

On Mon, 2010-08-02 at 11:47 +0200, Michael Adam wrote:
> Kai Blin wrote:
> > On Fri, 30 Jul 2010 17:47:25 +0200
> > Michael Adam <obnox at samba.org> wrote:
> > 
> > > This mail is to request that this code still gets into the
> > > 3.6 release, even though I did not manage to polish my
> > > patchset before the pre1 release.
> > [...]
> > > 1. The id mapping API should just consist of the methods
> > >     - sids_to_unixids
> > >     - unixids_to_sids
> > >    These calls should be atomic and the backend should know by itself
> > >    whether it needs to allocate some ids, store mappings and how.
> > >    To the caller, this should be completely irrelevant.
> > 
> > 
> > I really think this will make using winbindd from Samba4 much, much
> > easier. Basically, this is the central API Samba4 is using already.
> > Also, this changes allows us to use the concept of SID<->unixid
> > mappings in the S3 code, which again matches with what Metze and I came
> > up with when working on the S4 idmapping code in 2007.
> > 
> > I didn't get around to look at the actual patches yet, but I think
> > simplifying the idmap code while also moving the S3 and S4
> > implementations closer together is a good thing.
> 
> Right, this is a good thing. Andrew also liked this when I
> chatted with him some 3 or 4 weeks ago.

Yeah, it was a good conversation.  I'm naturally very interested in
anything that can unify this API.  One extension that I would like is to
see the IDMAP_BOTH concept available in this API.  That is, that both a
UID and a GID be reserved for a given SID, and that these be the same
value. 

> What I forgot to mention in my initial email are the possible
> next steps.
> 
> * Further simplify and unify the config (--> "idmap range" already
>   mentioned).
> 
>   As mentioned in the inital mail, the ldap-related config
>   options are basically as is for now to be least disruptive
>   for existing installations. I would like to get rid of as
>   many of the parameters as possible. (Is it really necessary
>   to make all the location and credentials of the id counter
>   configurable separately from the id mappings settings now
>   that the alloc code is subordinate?..). Remaining necessary
>   alloc-parameters should be moved underneath the
>   "idmap config DOMAIN : ..." layer for consistency.
> 
> * Reconcile the backends tdb and tdb2 into a single backend
>   again. As I said, the only differences consist in a format
>   upgrade code path that only tdb has on the one hand side and
>   the idmap script feature that only tdb2 has on the other hand
>   side. These should be only ona backend.
> 
>   I even had the idea of making the idmap script more universal.
>   Having it as a parametric option "idmap:script" that makes
>   the tdb2 backend behave differently is somehow a very arbitrary
>   hack. I could imagine making "script" a fully fledged idmap
>   backend of its own.
> 
> * While the idmap API speaks plural, the server code only uses
>   the sids_to_unixids and unixids_to_sids calls only in singular
>   through the winbindd api. This should be changed, for instance
>   in order to really take advantage of the atomicity of the
>   sids_to_unixids calls in tdb and tdb2: Mutlitple SIDS of a
>   user's token (e.g.) should be resolved in one atomic operation.

Yeah, I always found it a bit odd how we had only a partial
implementation of this API feature. 

> Some more radical changes I would like to see but which I need
> to think some more about are these:
> 
> * I'd like to have winbindd be responisble for all sid<->uid
>   mappings, also for passdb. This would greatly simplify the
>   code. THis would also make the "always give passdb a chance
>   first" code path vanish - passdb would ask winbindd instead.

The idea originally that passdb knows the unix UID best, and so should
be able to supply the ID mapping has caused just too much pain.  It is
better indeed to have the one single idmapping engine, and for backends
like LDAP, to have this configured to read the same actual entries, but
via a different route. 

> * Group mapping always puzzles me, and I think this should
>   be integrated with id mapping.

I certainly think that the ID component of group mapping should.  The
rest of group mapping is about marking the group type and possibly a
'windows name' right?

> I have probably probably missed something, but anyhow..

I'm certain you have, but that's not a criticism, simply a note of how
complex and hairy this whole area is.

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Cisco Inc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20100803/493d324f/attachment.pgp>