yet another idmap rewrite - still for 3.6 ?
Stefan (metze) Metzmacher
metze at samba.org
Wed Aug 4 03:09:27 MDT 2010
>>>> 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
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
>> 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.
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 262 bytes
Desc: OpenPGP digital signature
More information about the samba-technical