IDMAP_BOTH support in smbd
Stefan (metze) Metzmacher
metze at samba.org
Wed Mar 21 15:23:01 MDT 2012
>> OK, so where I was caught out is on the smbd side of the winbindd pipe,
>> they call down to different wbc calls, and I wasn't able to yet prove
>> that the type of ID asked for is always disregarded (particularly in
>> terms of not staining the cache with a UID or GID, if the underlying
>> backend stored a IDMAP_BOTH). If this is already handled, then great!
> No, IIRC we always ask for a uid or gid type. You would need to add a
> new type so that winbindd knows you are asking for the 'both' type.
> However you will end up with backends that do not support this new type,
> so you need also to find out how to handle the case.
That's not a problem.
>>>> - consolidate the caching layer in such a way that IDMAP_BOTH can be
>>>> To do this, I will need to determine if the winbindd idmap code is
>>>> dependent on the type of ID asked for: That is, if we move from
>>>> wbcSidToUid() to wbcSidsToUnixIds(), will the returned values change at
>>> See the comment above.
>>> Also see that we are exposing the plural sids_to_unixids to the
>>> winbindd api already and using it in some (not all) places.
>>> The server implementation is in
>> Indeed, the fact that this is only used for the logon token processing
>> is confusing.
> If you think about it you'll understand it is the only place where you
> really _need_ it. In other places it can be a nice to have.
No, the acl mapping code also needs it and that is actually the problem.
As the acl code generates posix aces for users instead of groups,
if a mapping uses IDMAP_BOTH.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 262 bytes
Desc: OpenPGP digital signature
More information about the samba-technical