I'm using Ruby/SMB module and libsmbclient.so to browse
files on Samba shares and its domain\owner information.
When I ask the smbd domain\owner for a file via libsmbclient
(i.e. query "system.nt_sec_desc.owner+" xattr by
clictx->getxattr() or smbc_getxattr()), the smbd crashes sometime.
I wrote a patch to prevent the smbd crashing, but I don't know
why api_lsa_lookup_sids() fails...
[2007/06/08 22:20:36, 4] rpc_server/srv_lsa_hnd.c:find_policy_by_hnd_internal(176)
Policy not found:  01 00 00 00 00 00 00 00 28 BF 65 30 F3 2A 00 00 ........ (.e0.*..
 A0 BF 65 30 ..e0
[2007/06/08 22:20:36, 5] rpc_parse/parse_prs.c:prs_debug(84)
[2007/06/08 22:20:36, 5] rpc_parse/parse_prs.c:prs_uint32(710)
0000 ptr_dom_ref: 00000000
[2007/06/08 22:20:36, 6] rpc_parse/parse_prs.c:prs_debug(84)
000004 lsa_io_trans_names names
[2007/06/08 22:20:36, 0] lib/fault.c:fault_report(41)
[2007/06/08 22:20:36, 0] lib/fault.c:fault_report(42)
INTERNAL ERROR: Signal 11 in pid 32121 (3.0.25a)
Please read the Trouble-Shooting section of the Samba3-HOWTO
[2007/06/08 22:20:36, 0] lib/fault.c:fault_report(44)
[2007/06/08 22:20:36, 0] lib/fault.c:fault_report(45)
[2007/06/08 22:20:36, 0] lib/util.c:smb_panic(1632)
PANIC (pid 32121): internal error
[2007/06/08 22:20:36, 0] lib/util.c:log_stack_trace(1736)
BACKTRACE: 20 stack frames:
#0 /usr/sbin/smbd(log_stack_trace+0x1c) [0x60bf8c]
#1 /usr/sbin/smbd(smb_panic+0x43) [0x60c073]
#2 /usr/sbin/smbd [0x5f9ea2]
#3 /lib/libpthread.so.0 [0x2b9633d10110]
#4 /usr/sbin/smbd(prs_uint32+0x170) [0x4fba40]
#5 /usr/sbin/smbd [0x5747b0]
#6 /usr/sbin/smbd(lsa_io_r_lookup_sids+0x89) [0x575699]
#7 /usr/sbin/smbd [0x514c7a]
#8 /usr/sbin/smbd(api_rpcTNP+0x169) [0x56c4e9]
#9 /usr/sbin/smbd(api_pipe_request+0x168) [0x56ca38]
#10 /usr/sbin/smbd [0x566efe]
#11 /usr/sbin/smbd [0x566f72]
#12 /usr/sbin/smbd [0x473283]
#13 /usr/sbin/smbd [0x473662]
#14 /usr/sbin/smbd(reply_trans+0x705) [0x4744f5]
#15 /usr/sbin/smbd [0x4c5884]
#16 /usr/sbin/smbd(smbd_process+0x7b1) [0x4c6b31]
#17 /usr/sbin/smbd(main+0xa20) [0x6bb6a0]
#18 /lib/libc.so.6(__libc_start_main+0xf4) [0x2b9634e3f8e4]
#19 /usr/sbin/smbd [0x45a229]
Created attachment 2735 [details]
smbd log (log level = 10)
Created attachment 2736 [details]
stack trace by gdb
Created attachment 2737 [details]
packet data (wireshark/libpcap)
Created attachment 2738 [details]
Created attachment 2739 [details]
Proposed patch: fix api_lsa_lookup_sids() crashing
Remember this proposed patch does NOT fix the "Policy not found" problem.
This bug can be reproduced by Samba 3.0.24 on Debian(i386 and amd64)
and Samba 3.0.25a on Debian(i386) too.
Jerry, this should be a showstopper for 3.0.25b,
I'm working on this.
Created attachment 2740 [details]
This should fix it correctly - please let me know !
Created attachment 2741 [details]
Sorry, you'll need this patch to apply on top of the previous one.
Got bitten by a talloc hierarchy. Make sure we alloc
off the pipe ctx now ->names is part of the containing
Created attachment 2742 [details]
I've tested Samba 3.0.25a plus Jeremy's patches and got
another crash problem. `rpcclient -c "lookupsids SID"`
always fails and crashes smbd.
Where you looking for the string "SID" or actually a valid SID.
Your report doesn't make this clear. I valgrinded my fixes in the SAMBA_3_0_25 tree and tested both valid and invalid SID lookups (which was how I found the auxiliary patch was needed). Both worked. Can you test out of the SAMBA_3_0_25 tree please as this is what will be in 3.0.25b ? In the meantime I'm trying to reproduce your problem.
Ok, just tested out of the SAMBA_3_0_25 svn tree and can't reproduce your problem either with or without valgrind. I think there's probably another fix already in the SAMBA_3_0_25 tree that is needed. As we'll be releasing out of the cumulative patches in SAMBA_3_0_25 then I think this is fixed.
can you check (and mark as duplicate) if this is the same bug as reported in #4668, to me they seem to deal with the same stuff and the stack trace seem identical.
OK. I've tested SAMBA_3_0_25 r23407 and confirmed this bugs has been fixed.
*** Bug 4668 has been marked as a duplicate of this bug. ***