Winbind Sid-to-Name handling

[Richard Sharpe]

On Fri, Sep 27, 2013 at 7:46 AM, Har Gagan Sahai <shargagan at novell.com> wrote:
> Hi Samba Team,
>
> Please provide some input on this issue.

Have you considered upgrading to a more recent version of Samba? Does
that eliminate the problem?

Have you searched in bugzilla for winbindd bugs to see if any might apply?


> Regards,
> Har Gagan Sahai
>
>>>> "Har Gagan Sahai" <shargagan at novell.com> 09/25/13 7:31 PM >>>
>
> Hi Samba Team,
>
> We are using samba-3.6.3. I am facing one issue wrt winbind rpc lookup domain sids.
>
> There are continuous requests hitting winbind for different lookup sids requests. These requests vary in the number of sids in each request. So some requests (single sid) are done fast and others takes time.
>
> Now when there are requests which is taking time, those times out and it does retry as per the current code in lookup_groupmem() in winbindd_ads.c. This retry also times out due to delay in the response. This delay can be attributed to the number of sids in the request.
>
> After a few time out instances, for any new request of sid-to-name type, I have noticed that the response is varying. Sometime it picks up the response of the previously timed out sid-to-name command of some other SID(s). Here is the output of the command I ran in loop, 'wbinfo -s S-1-5-21-3842980903-586396-300088805-513'.
> SOMEDOMAIN\testgroup1 2
> SOMEDOMAIN\Domain Users 2
> SOMEDOMAIN\puser100 1
>
> The correct name is 'Domain Users' but other two are wrong names picked due to the problem I explained above.
>
> And in other case, it also causes crash. This is when the response has lesser number of names compared to the requested sids. The backtrace looks like this :
>
> [2013/09/25 14:38:44.038152,  0, pid=919] lib/fault.c:51(fault_report)
>   ===============================================================
> [2013/09/25 14:38:44.038215,  0, pid=919] lib/util.c:1117(smb_panic)
>   PANIC (pid 919): internal error
> [2013/09/25 14:38:44.042673,  0, pid=919] lib/util.c:1221(log_stack_trace)
>   BACKTRACE: 23 stack frames:
>    #0 /usr/sbin/winbindd(log_stack_trace+0x1a) [0x7f603b1c1a9a]
>    #1 /usr/sbin/winbindd(smb_panic+0x2b) [0x7f603b1c1b6b]
>    #2 /usr/sbin/winbindd(+0x1af280) [0x7f603b1b2280]
>    #3 /lib64/libc.so.6(+0x32bd0) [0x7f6038278bd0]
>    #4 /lib64/libc.so.6(+0x809d2) [0x7f60382c69d2]
>    #5 /usr/lib64/libtalloc.so.2(talloc_strdup+0x36) [0x7f6038bf7b36]
>    #6 /usr/sbin/winbindd(+0x5036c1) [0x7f603b5066c1]
>    #7 /usr/sbin/winbindd(dcerpc_lsa_lookup_sids+0x2e) [0x7f603b506d7e]
>    #8 /usr/sbin/winbindd(winbindd_lookup_sids+0xf5) [0x7f603b0ff965]
>    #9 /usr/sbin/winbindd(+0xfffd2) [0x7f603b102fd2]
>    #10 /usr/sbin/winbindd(+0xec5b0) [0x7f603b0ef5b0]
>    #11 /usr/sbin/winbindd(_wbint_LookupGroupMembers+0x63) [0x7f603b10d593]
>    #12 /usr/sbin/winbindd(+0x113e06) [0x7f603b116e06]
>    #13 /usr/sbin/winbindd(winbindd_dual_ndrcmd+0xe1) [0x7f603b10c2d1]
>    #14 /usr/sbin/winbindd(+0x108032) [0x7f603b10b032]
>    #15 /usr/sbin/winbindd(+0x108b55) [0x7f603b10bb55]
>    #16 /usr/sbin/winbindd(tevent_common_loop_immediate+0xea) [0x7f603b1d285a]
>    #17 /usr/sbin/winbindd(run_events_poll+0x3b) [0x7f603b1d0abb]
>    #18 /usr/sbin/winbindd(+0x1ce1f2) [0x7f603b1d11f2]
>    #19 /usr/sbin/winbindd(_tevent_loop_once+0x90) [0x7f603b1d15f0]
>    #20 /usr/sbin/winbindd(main+0x7db) [0x7f603b0e344b]
>    #21 /lib64/libc.so.6(__libc_start_main+0xe6) [0x7f6038264c16]
>    #22 /usr/sbin/winbindd(+0xddb49) [0x7f603b0e0b49]
> [2013/09/25 14:38:44.063980,  0, pid=919] lib/fault.c:372(dump_core)
>   dumping core in /var/log/samba/cores/winbindd
>
> The question is how winbind differentiate b/w the responses. That is when there is a response for any timeout-ed request arrives,  can it pose as the response of a new request done after the time out of previous request  ?
>
> Regards,
> Har Gagan Sahai
>
>



-- 
Regards,
Richard Sharpe
(何以解憂？唯有杜康。--曹操)