Hello, I'm facing a bug with winbind. If I request groups for particular domain user, winbind cache gets corrupted. My winbind version is 4.1.12-23.el7_1 (Centos 7.1, x86_64). 1) this is correct UID to SID mapping: wbinfo -U 100152 S-1-5-21-3451901064-902568176-4053310204-180212 2) I request groups info for a user: id -G -n 209459 [reply with 33 groups] 3) I request UID to SID mapping again: wbinfo -U 100152 S-1-5-21-3135676852-3361659551-265282358-180212 and it is different. So it looks like corruption somewhere. Before I start to debug, is this a known problem possibly fixed in winbind 4.2.x version? -- Luk?? Hejtm?nek
On Tue, Jun 16, 2015 at 02:21:25PM +0200, Lukas Hejtmanek wrote:> Hello, > > I'm facing a bug with winbind. If I request groups for particular domain user, > winbind cache gets corrupted. My winbind version is 4.1.12-23.el7_1 (Centos > 7.1, x86_64). > > 1) this is correct UID to SID mapping: > wbinfo -U 100152 > S-1-5-21-3451901064-902568176-4053310204-180212 > > 2) I request groups info for a user: > id -G -n 209459 > [reply with 33 groups] > > 3) I request UID to SID mapping again: > wbinfo -U 100152 > S-1-5-21-3135676852-3361659551-265282358-180212 > > and it is different. So it looks like corruption somewhere. Before I start to > debug, is this a known problem possibly fixed in winbind 4.2.x version?Not that I know of. Can you run winbindd under valgrind ? Should help debug this.
On Tue, Jun 16, 2015 at 09:12:24AM -0700, Jeremy Allison wrote:> Not that I know of. Can you run winbindd under valgrind ? > Should help debug this.this is the only waring regardless read/write that valgrind reports: ==16475== Syscall param writev(vector[...]) points to uninitialised byte(s) ==16475== at 0xBB32337: writev (in /usr/lib64/libc-2.17.so) ==16475== by 0xA4AC8E4: writev_handler (async_sock.c:514) ==16475== by 0xB5EE30A: ??? (in /usr/lib64/libtevent.so.0.9.21) ==16475== by 0xB5EC7D6: ??? (in /usr/lib64/libtevent.so.0.9.21) ==16475== by 0xB5E8FBC: _tevent_loop_once (in /usr/lib64/libtevent.so.0.9.21) ==16475== by 0xB5EA28E: tevent_req_poll (in /usr/lib64/libtevent.so.0.9.21) ==16475== by 0x5AD310D: tevent_req_poll_ntstatus (tevent_ntstatus.c:106) ==16475== by 0x6EF09AA: dcerpc_binding_handle_call (binding_handle.c:565) ==16475== by 0x69AE98C: dcerpc_lsa_LookupSids_r (ndr_lsa_c.c:3037) ==16475== by 0x69AEC1C: dcerpc_lsa_LookupSids (ndr_lsa_c.c:3192) ==16475== by 0x152FD6: rpc_lookup_sids (winbindd_rpc.c:1145) ==16475== by 0x15D304: _wbint_LookupSids (winbindd_dual_srv.c:90) ==16475== Address 0x1bc3edde is 590 bytes inside a block of size 1,317 alloc'd ==16475== at 0x4C29BFD: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==16475== by 0xAAD6423: _talloc_pooled_object (in /usr/lib64/libtalloc.so.2.1.1) ==16475== by 0xB5E9E2D: _tevent_req_create (in /usr/lib64/libtevent.so.0.9.21) ==16475== by 0x95E07F0: smb1cli_req_create (smbXcli_base.c:1259) ==16475== by 0x95E2FD3: smb1cli_trans_send (smb1cli_trans.c:512) ==16475== by 0x7B9DA6D: cli_trans_send (clitrans.c:77) ==16475== by 0x7BAD413: tstream_cli_np_readv_trans_start (cli_np_tstream.c:814) ==16475== by 0x7BAE0EE: tstream_cli_np_readv_send (cli_np_tstream.c:705) ==16475== by 0x8F179DC: tstream_readv_send (tsocket.c:573) ==16475== by 0x8F17F8B: tstream_readv_pdu_ask_for_next_vector (tsocket_helpers.c:286) ==16475== by 0x8F18420: tstream_readv_pdu_send (tsocket_helpers.c:199) ==16475== by 0x8F1849A: tstream_readv_pdu_queue_trigger (tsocket_helpers.c:402) -- Luk?? Hejtm?nek