Bug 2214327 - wbinfo lists domain users from trusted domain only after second call
Summary: wbinfo lists domain users from trusted domain only after second call
Keywords:
Status: VERIFIED
Alias: None
Product: Red Hat Enterprise Linux 9
Classification: Red Hat
Component: samba
Version: 9.3
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Andreas Schneider
QA Contact: sssd-qe
URL:
Whiteboard:
Depends On:
Blocks: 2221600
TreeView+ depends on / blocked
 
Reported: 2023-06-12 16:11 UTC by Denis Karpelevich
Modified: 2023-07-14 08:39 UTC (History)
3 users (show)

Fixed In Version: samba-4.18.4-101.el9
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 2221600 (view as bug list)
Environment:
Last Closed:
Type: Bug
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker RHELPLAN-159540 0 None None None 2023-06-12 16:16:39 UTC
Red Hat Issue Tracker SSSD-6312 0 None None None 2023-06-20 09:56:53 UTC
Red Hat Issue Tracker SSSD-6313 0 None None None 2023-07-11 12:33:33 UTC
Samba Project 15398 0 None None None 2023-06-20 09:58:23 UTC

Comment 1 Andreas Schneider 2023-06-16 08:58:17 UTC
I'm not able to reproduce this locally. It works the first time and lists all users also from child domains.

Could you please set `winbind debug traceid = yes` (we should set it for all tests by default) and redo the log with log level 10. So I can see what is going on.

[2023/06/08 10:07:50.440781,  1] ../../source3/winbindd/wb_query_user_list.c:139(wb_query_user_list_recv)
  Failed with: NT_STATUS_NO_MEMORY


I don't see what returns NT_STATUS_NO_MEMORY in the child and why ...

Comment 3 Andreas Schneider 2023-06-20 09:51:19 UTC
The winbind child segfaults:

[2023/06/16 16:30:18.677249,  0, pid=28112, effective(0, 0), real(0, 0), traceid=35] ../../lib/cmdline/cmdline.c:56(_samba_cmdline_talloc_log)
  Bad talloc magic value - unknown value
[2023/06/16 16:30:18.677374,  0, pid=28112, effective(0, 0), real(0, 0), traceid=35] ../../lib/util/fault.c:173(smb_panic_log)
  ===============================================================
[2023/06/16 16:30:18.677388,  0, pid=28112, effective(0, 0), real(0, 0), traceid=35] ../../lib/util/fault.c:177(smb_panic_log)
  INTERNAL ERROR: Bad talloc magic value - unknown value in pid 28112 (4.18.3)
[2023/06/16 16:30:18.677398,  0, pid=28112, effective(0, 0), real(0, 0), traceid=35] ../../lib/util/fault.c:182(smb_panic_log)
  If you are running a recent Samba version, and if you think this problem is not yet fixed in the latest versions, please consider reporting this bug, see https://wiki.samba.org/index.php/Bug_Reporting
[2023/06/16 16:30:18.677408,  0, pid=28112, effective(0, 0), real(0, 0), traceid=35] ../../lib/util/fault.c:183(smb_panic_log)
  ===============================================================
[2023/06/16 16:30:18.677420,  0, pid=28112, effective(0, 0), real(0, 0), traceid=35] ../../lib/util/fault.c:185(smb_panic_log)
  PANIC (pid 28112): Bad talloc magic value - unknown value in 4.18.3
[2023/06/16 16:30:18.677698,  0, pid=28112, effective(0, 0), real(0, 0), traceid=35] ../../lib/util/fault.c:293(log_stack_trace)
  BACKTRACE: 22 stack frames:
   #0 /usr/lib64/samba/libgenrand-samba4.so(log_stack_trace+0x34) [0x7fcc04ad35d4]
   #1 /usr/lib64/samba/libgenrand-samba4.so(smb_panic+0xd) [0x7fcc04ad382d]
   #2 /lib64/libtalloc.so.2(+0x3121) [0x7fcc04650121]
   #3 /usr/sbin/winbindd(_wbint_InitConnection+0xe8) [0x55aa1fd79028]
   #4 /usr/sbin/winbindd(+0x59488) [0x55aa1fd7e488]
   #5 /lib64/libdcerpc-server-core.so.0(dcesrv_call_dispatch_local+0x69) [0x7fcc05890469]
   #6 /usr/sbin/winbindd(winbindd_dual_ndrcmd+0x3c5) [0x55aa1fd762d5]
   #7 /usr/sbin/winbindd(+0x4d664) [0x55aa1fd72664]
   #8 /lib64/libtevent.so.0(tevent_common_invoke_fd_handler+0x97) [0x7fcc03d2e707]
   #9 /lib64/libtevent.so.0(+0xef4f) [0x7fcc03d34f4f]
   #10 /lib64/libtevent.so.0(+0xcf5b) [0x7fcc03d32f5b]
   #11 /lib64/libtevent.so.0(_tevent_loop_once+0x95) [0x7fcc03d2d9b5]
   #12 /usr/sbin/winbindd(+0x4fd14) [0x55aa1fd74d14]
   #13 /usr/sbin/winbindd(+0x505cd) [0x55aa1fd755cd]
   #14 /lib64/libtevent.so.0(tevent_common_invoke_immediate_handler+0x182) [0x7fcc03d2ec72]
   #15 /lib64/libtevent.so.0(tevent_common_loop_immediate+0x27) [0x7fcc03d2eca7]
   #16 /lib64/libtevent.so.0(+0xed2f) [0x7fcc03d34d2f]
   #17 /lib64/libtevent.so.0(+0xcf5b) [0x7fcc03d32f5b]
   #18 /lib64/libtevent.so.0(_tevent_loop_once+0x95) [0x7fcc03d2d9b5]
   #19 /usr/sbin/winbindd(main+0xd34) [0x55aa1fd402f4]
   #20 /lib64/libc.so.6(__libc_start_main+0xe5) [0x7fcc0339dd85]
   #21 /usr/sbin/winbindd(_start+0x2e) [0x55aa1fd40e8e]
[2023/06/16 16:30:18.677828,  0, pid=28112, effective(0, 0), real(0, 0), traceid=35] ../../source3/lib/dumpcore.c:318(dump_core)
  coredump is handled by helper binary specified at /proc/sys/kernel/core_pattern


I think I have a fix for it, the issue probably got introduced with ccb6b75482c80572862ca7a189bfe26565f23b45


Note You need to log in before you can comment on or make changes to this bug.