IDMAP_BOTH support in smbd

[Stefan (metze) Metzmacher]

Hi,

>> 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
>>>> supported. 
>>>>
>>>> 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
>>>> all?
>>>
>>> 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
>>> source3/winbindd/winbindd_dual_srv.c:_wbint_Sids2UnixIDs()
>>
>> 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.

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/20120321/8aff7747/attachment.pgp>