rpcclient -c 'adddriver "Windows NT x86" "lp:..."' ends with the error quoted in summary. Samba log reports an INTERNAL ERROR, signal 11, which it advises to report as a bug. Upon closer inspection I assumed that the problem might be something that happens in tdb_store, possibly dereferencing a NULL pointer but I haven't made sufficient progress to pinpoint it. I don't know if it has anything to do with it but I also can't build the 2.2.8a because configure quits after this message: checking whether to use included popt... ./popt A few lines before there is also this suspicious diagnostic: checking whether or not getgroups returns EGID too many times...yes On my standby server with practically identical hardware and software (Siemens-Fujitsu Sceni L, i845 chipset, P4/2GHz, 768 MB RAM, SuSE 8.2 with 2.4.20-62) I can build 2.2.8a without problems, getgroups does not return EGID too many times and included popt is not used. I need some pointers for further trouble-shooting. Is there a document about the tdb's?
I found where the problem really occurs. It's the invocation of the procedure lib/system.c:sys_adminlog from this chunk of rpc_server/srv_spoolss_nt.c:_spoolss_addprinterdriver line 6662 6654 if (add_a_printer_driver(driver, level)!=0) { 6655 err = WERR_ACCESS_DENIED; 6656 goto done; 6657 } 6658 6659 /* BEGIN_ADMIN_LOG */ 6660 switch(level) { 6661 case 3: 6662 sys_adminlog(LOG_INFO,"Added printer driver. Print driver name: % s Print driver OS: %s. Administrator name: %s.", 6663 driver.info_3->name,drv_ver_to_os[driver.info_3- >cversion],uidtoname(user.uid)); 6664 fstrcpy(driver_name, driver.info_3->name); 6665 break; 6666 case 6: .................... 6671 } 6672 /* END_ADMIN_LOG */ I don't really hold it for essential, so I just closed, et violá the signal 11 is gone and rpcclient calls for all levels 1 2 3 don't segment and cupsaddsmb also works fine. Curiously it's the only place where this wrapper function is called. Lookit: 1307 /************************************************************************* 1308 Wrapper for Admin Logs. 1309 **************************************************************************/ 1310 1311 void sys_adminlog(int priority, const char *format_str, ...) 1312 { 1313 va_list ap; 1314 int ret; 1315 char **msgbuf = NULL; 1316 1317 if (!lp_admin_log()) 1318 return; 1319 1320 va_start( ap, format_str ); 1321 ret = vasprintf( msgbuf, format_str, ap ); 1322 va_end( ap ); 1323 1324 if (ret == -1) 1325 return; 1326 1327 #if defined(HAVE_SYSLOG) 1328 syslog( priority, "%s", *msgbuf ); 1329 #else 1330 DEBUG(0,("%s", *msgbuf )); 1331 #endif 1332 SAFE_FREE(*msgbuf); 1333 } Can someone fix it? Cause it's actually essential to be able to show the boss who set up the printers.
Is it possible to get a stack backtrace on exactly what is crashing? That would help speed things along. If you could do something like panic action = /usr/bin/X11/xterm -display localhost:0 -e gdb /proc/%d/exe %d in your smb.conf file and send the results of 'backtrace' that would be good.
Do you have any more info on why configure dies after the included popt message? Displaying ./popt is the correct response when the machine you are building on does not have the popt library installed. I don't think the EGID message is relevant.
here's backtrace: #0 0x4025ec17 in waitpid () from /lib/libc.so.6 #1 0x401f10f4 in do_system () from /lib/libc.so.6 #2 0x0816558b in smb_panic () #3 0x081533a1 in fault_report () #4 0x081533fe in sig_fault () #5 <signal handler called> >>>#6 0x4021a43e in vasprintf () from /lib/libc.so.6 #7 0x081585f2 in sys_adminlog () #8 0x080fdb50 in _spoolss_addprinterdriver () #9 0x080f05f8 in api_spoolss_addprinterdriver () #10 0x080ec957 in api_rpcTNP () #11 0x080f1c25 in api_spoolss_rpc () #12 0x080ec76b in api_pipe_request () #13 0x080da34d in process_request_pdu () #14 0x080da542 in process_complete_pdu () #15 0x080da7b0 in process_incoming_data () #16 0x080da944 in write_to_pipe () #17 0x08077224 in api_fd_reply () #18 0x0807748f in named_pipe () #19 0x08077e68 in reply_trans () #20 0x080ae29a in switch_message () #21 0x080ae34a in construct_reply () #22 0x080ae529 in process_smb () #23 0x080aefdd in smbd_process () #24 0x0806b42a in main () #25 0x401c38ae in __libc_start_main () from /lib/libc.so.6 The singal comes when sys_adminlog calls vasprintf
popt: both popt and popt-devel (popper too) are installed on both computers. Should I reinstall them? EGID: it still bothers me that one computer says no the, other one says yes, although they are virtually identical. The difference is that one of them has a SCSI RAID controller from Compaq and the other only a Tekram SCSI Card.
Actually there is an additional problem when rpcclient's command "enumdriver 3" is invoked. It aborts with segmentation fault, the other levels (2 and 1) are ok after the sys_adminlog is commented out. The fault comes from the careless line number 944 of the following function strlen_w in lib/util_unistr.c: 936 /******************************************************************* 937 Count the number of characters in a smb_ucs2_t string. 938 ********************************************************************/ 939 940 size_t strlen_w(const smb_ucs2_t *src) 941 { 942 size_t len; 943 944 for(len = 0; *(src++); len++) 945 ; 946 947 return len; 948 } The code is not suited to count string length of an empty string. I've rephrased the offending line 944 as: 944 for(len = 0; src && *(src++); len++) -------------------^^^^^^^ and then level 3 enumdrivers works just fine, like this: # rpcclient -Uroot -c 'enumdrivers 3' localhost cmd = enumdrivers 3 [Windows NT x86] Printer Driver Info 3: Version: [3] Driver Name: [lp] Architecture: [Windows NT x86] Driver Path: [\\localhost\print$\W32X86\3\lexpsnt3.dll] Datafile: [\\localhost\print$\W32X86\3\OPC720.PPD] Configfile: [\\localhost\print$\W32X86\3\LEXPSNTU.DLL] Helpfile: [\\localhost\print$\W32X86\3\LEXPSNT.HLP] Dependentfiles: [\\localhost\print$\W32X86\3\LEXUNST.ZIP] Dependentfiles: [\\localhost\print$\W32X86\3\PTZIPW32.DLL] Dependentfiles: [\\localhost\print$\W32X86\3\LEXPPDS.ZIP] Dependentfiles: [\\localhost\print$\W32X86\3\LEXEDF.DLL] Dependentfiles: [\\localhost\print$\W32X86\3\LEXCFI.DLL] Dependentfiles: [\\localhost\print$\W32X86\3\LMPCLTHK.DLL] Dependentfiles: [\\localhost\print$\W32X86\3\E32XBM.DLL] Dependentfiles: [\\localhost\print$\W32X86\3\C910BM.DLL] Dependentfiles: [\\localhost\print$\W32X86\3\C750BM.DLL] Dependentfiles: [\\localhost\print$\W32X86\3\C720BM.DLL] Dependentfiles: [\\localhost\print$\W32X86\3\C710BM.DLL] Dependentfiles: [\\localhost\print$\W32X86\3\T62XBM.DLL] Dependentfiles: [\\localhost\print$\W32X86\3\T61XBM.DLL] Dependentfiles: [\\localhost\print$\W32X86\3\M410BM.DLL] Dependentfiles: [\\localhost\print$\W32X86\3\W820BM.DLL] Dependentfiles: [\\localhost\print$\W32X86\3\W810BM.DLL] Dependentfiles: [\\localhost\print$\W32X86\3\E855BM.DLL] Dependentfiles: [\\localhost\print$\W32X86\3\OC45BM.DLL] Dependentfiles: [\\localhost\print$\W32X86\3\OC40BM.DLL] Dependentfiles: [\\localhost\print$\W32X86\3\OC1200BM.DLL] Dependentfiles: [\\localhost\print$\W32X86\3\K1220BM.DLL] Dependentfiles: [\\localhost\print$\W32X86\3\SC1275BM.DLL] Dependentfiles: [\\localhost\print$\W32X86\3\OPTRASBM.DLL] Dependentfiles: [\\localhost\print$\W32X86\3\LEXPSNT.ALL] Dependentfiles: [\\localhost\print$\W32X86\3\LEXDRVIN.EXE] Dependentfiles: [\\localhost\print$\W32X86\3\DRVNPANT.DLL] Dependentfiles: [\\localhost\print$\W32X86\3\LEXMV95.HLP] Dependentfiles: [\\localhost\print$\W32X86\3\PTAPIW32.DLL] Dependentfiles: [\\localhost\print$\W32X86\3\PTRESW32.DLL] Dependentfiles: [\\localhost\print$\W32X86\3\PTGUIW32.DLL] Dependentfiles: [\\localhost\print$\W32X86\3\LEXPSNT.CNT] Dependentfiles: [\\localhost\print$\W32X86\3\LEXPSHOW.HLP] Dependentfiles: [\\localhost\print$\W32X86\3\LEXFNTRC.DLL] Dependentfiles: [\\localhost\print$\W32X86\3\LEXDRVX.DLL] Dependentfiles: [\\localhost\print$\W32X86\3\LEXPSLNG.DLL] Monitorname: [] Defaultdatatype: [RAW] instead of like this: # rpcclient -Uroot%zima66 -c 'enumdrivers 3' localhost cmd = enumdrivers 3 [Windows NT x86] Segmentation fault
EGID: It still worries me like hell that configure should report that getgroups returns EGIDs too many times on my production server. It will probably bomb when the CEO tries to use a samba share and then they'll find out it's not a Win2K Advanced Server.
The strlen_w change isn't the correct fix I'm afraid. It's supposed to core dump under those circumstances. Can you get me a stack backtrace of rpcclient showing the caller of strlen_w please ? Jeremy.
[Looks like jeremy beat me to the fix for the string problem] Dragen, if you're really worred about the EGID problem then you can try running the configure test by hand. From reading the code in configure.in and smbd/password.c where the test results are used, it seems that some OSes return the same gid for element 0 and element 1 of the returned array. However the comment in smbd/password.c seems to imply that sometimes the zeroth element of the group array is zero which would lead to a security problem! Now if this test was run as root I guess you might be accidentally triggering it and it would incorrectly say EGID was returning the wrong result. Can you run the test problem in the same context you are running configure? I'd be curious to see what the results were. #include <sys/types.h> #include <stdio.h> int main(int argc, char *argv[]) { gid_t groups[10]; int n = 10; n = getgroups(n, &groups); /* Could actually pass back the number of EGIDs there ... */ printf("n = %d\n", n); if (n >= 2) printf("groups[0] = %d, groups[1] = %d\n", groups[0], groups[1]); exit((n > 1 && groups[0] == getegid() && groups[1] == getegid()) ? 1 : 0); }
I'm sorry, Jerry, I thought you knew where it is called from in rpcclient. Here's the backtrace when it hits the NULL pointer. #0 0x0809ee19 in strlen_w (src=0x0) at lib/util_unistr.c:944 #1 0x080a04ba in rpcstr_pull (dest=0xbfffcd80 "", src=0x0, dest_len=256, src_len=0, flags=1) at lib/util_unistr.c:2092 #2 0x08068f78 in display_print_driver_3 (i1=0x0) at rpcclient/cmd_spoolss.c:688 #3 0x08069601 in cmd_spoolss_enum_drivers (cli=0x8176590, mem_ctx=0x8175908, argc=-1073754752, argv=0xbfffcd80) at rpcclient/cmd_spoolss.c:876 #4 0x08063590 in do_cmd (cli=0x8176590, cmd_entry=0x812248c, cmd=0x813de20 "enumdrivers 3") at rpcclient/rpcclient.c:504 #5 0x080636e4 in process_cmd (cli=0xbfffcd80, cmd=0x813de20 "enumdrivers 3") at rpcclient/rpcclient.c:563 #6 0x08063ef9 in main (argc=6, argv=0xbffff374) at rpcclient/rpcclient.c:797 #7 0x402348ae in __libc_start_main () from /lib/libc.so.6
Tim, I ran your example and it printed "n = 1", return code 0, on both machines. However, on one machine it says checking whether or not getgroups returns EGID too many times... no and proceeds to build samba whereas on the other machine it says checking whether or not getgroups returns EGID too many times... yes and then 3 more tests and then it says: checking whether to use included popt... ./popt checking configure summary... configure: error: summary failure. Aborting config Bad exit status from /var/tmp/rpm-tmp.25290 (%build) Instead of just checking whether to use included popt... no and go on building samba. What gives?
Fixed this in the 2.2 codbase. It was a missing check for null in rpcstr_pull() in 2.x. This is already fixed in 3.x and above. Jeremy.
done
Created attachment 62 [details] fixes the problem of malfunctioning rpcclient calls I'm new to samba. I suggested the changes necessary in the source code of lib/util_unistr.c and rpc_server/srv_spoolss_nt.c without checking in a patch file. Since samba posters increasingly bump against this problem I think it is necessary to fill the gap. Since the status is fixed/closed, does it mean that there is link to a cvs diff ?
Created attachment 85 [details] required files to build a SuSE samba 2.2.8a release 4 This file should be unbzip22ed and untarred in /usr/src/packages/SOURCES for a clean SuSE 8.2 build of samba 2.2.8a-3 including patches for bugs #52, this bug #82 and #102, plus an obscure injunction in dosmode.c ("We never make directories readonly for the owner...), which spoils some features of Explorer shell is removed (see acl-mapping-fixes.diff lines 216/225). Release number is changed to 4 for clean update. The build is started with "rpm -bb samba.spec". Installable packages will be put in /usr/src/packages/RPMS/i386: libsmbclient-2.2.8a-4.i386.rpm libsmbclient-devel-2.2.8a-4.i386.rpm samba-2.2.8a-4.i386.rpm samba-client-2.2.8a-4.i386.rpm samba-doc-2.2.8a-4.i386.rpm samba-vscan-0.3.2a-0.i386.rpm Many users complain having problems with rpcclient. Usually this bug #82. To some I had to send this compressed archive in order to fix the problem. So it may as well be an attachment for future reference. The bug should have been fixed, perhaps in a slightly different way, but there is no link to RCS/CVS from here, as Mr. Milne noted. Can someone fix that?
database cleanup