yet another idmap rewrite - still for 3.6 ?

[Stefan (metze) Metzmacher]

Hi Michael,

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

I also like it:-)

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

Yes, that makes things much easier to implement things
like: let domain admins being the owner of a file.

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

+1

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

+1

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

Sounds very good.

> 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 think we should get rid of group mapping and have complete group support.
IDMAP would be the only place where we map a SID to a unix uid/gid.

metze

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20100804/890dd4f2/attachment.pgp>