Summary:	ASTERISK-16808: Missing error message from System() app, if sh binary is missing
Reporter:	Bernd Wittefeld (bernd)	Labels:
Date Opened:	2010-10-13 10:09:44	Date Closed:	2011-01-06 14:55:36.000-0600
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Applications/app_system
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	Asterisk was run in a change root using chroot. The System() calls from the dialplan ended with $SYSTEMSTATUS = APPERROR. No error message about a missing sh binary was given, making it hard to debug the error. This problem should appear not only when using chroot, but everytime the sh binary could not be found (for some reason).
Comments:	By: Paul Belanger (pabelanger) 2010-10-13 10:11:28 Any information about reproducing, or actual error will help. --- We require a complete debug log to help triage the issue. This document will provide instructions on how to collect debugging logs from an Asterisk machine for the purpose of helping bug marshals troubleshoot an issue: http://svn.digium.com/svn/asterisk/trunk/doc/HOWTO_collect_debug_information.txt By: David Woolley (davidw) 2010-10-13 11:58:58 I have't checked, but I assume it uses system(3).  In that case, a missing shell is indinguishable from exit(127) in the actual command. By: Stefan Schmidt (schmidts) 2010-10-13 13:48:33 i have looked at this part of code today and i think the problem would occur here: http://www.asterisk.org/doxygen/asterisk1.6.2/asterisk_8c-source.html#l01053 there is a direct execl call using /bin/sh as parameter. By: Stefan Schmidt (schmidts) 2010-10-14 05:37:35 maybe asterisk should check on module_load if /bin/sh is available or not and stops loading the app_system module. not so good idea, i have tried this. By: Stefan Schmidt (schmidts) 2010-10-14 06:29:05 please see the attached file this will give you a warning if /bin/sh is not available if the command will be launched. By: David Woolley (davidw) 2010-10-14 06:45:48 Firstly, it seems to me, especially given that the standard libc equivalent doesn't do anything very special in this case, that this is a feature request, not a bug. Secondly, ast_log is being run in a new process, and a different address space.  I think that will mean that any interlocking that prevents log messages getting interleaved will not be effective.  There may be other weird race conditions, e.g. during log rolling. By: Stefan Schmidt (schmidts) 2010-10-14 07:24:39 ast_log is used on certain other places even in this function so i dont think this could be a problem. as far as i have seen there is no check in asterisk if /bin/sh exists for the user which started asterisk, neither on startup or on the system function call. as the reporter said there is no information why a system call doesnt work if /bin/sh could not be found. By: David Woolley (davidw) 2010-10-14 07:47:11 There is one other place where it is run in the wrong process (unless called indirectly).  Only the bit between the fork and the else matters. This code will fail if you run non-root, on many non-Linux systems, and will also fail if /bin/sh is not executable. It will also fail if any dependency of /bin/sh is missing, e.g. on our system, these would include:        linux-gate.so.1 =>  (0x00bdc000)        libtermcap.so.2 => /lib/libtermcap.so.2 (0x047d1000)        libdl.so.2 => /lib/libdl.so.2 (0x00cf5000)        libc.so.6 => /lib/libc.so.6 (0x00110000)        /lib/ld-linux.so.2 (0x00b69000) (These are probably dependencies of asterisk, so if the chroot is outside of asterisk, you may get away with it.) By: Walter Doekes (wdoekes) 2010-10-14 07:53:27 > ast_log is used on certain other places even in this function so i dont think this could be a problem. Well actually. Above that line it says: """/* Careful with order! Logging cannot happen after we close FDs */""" And you're doing logging after closing the FD's. I'm with davidw here. You're missing the +x check. You miss dependency checks. And you introduce a rather redundant fopen/fclose for every System() call. If you really want to do this, I'd go with either checking at load(app_system.so)-time or after a failed execl call (do _exit(99) or some other unlikely return value and check for that). By: Stefan Schmidt (schmidts) 2010-10-14 09:19:45 thanks on your comments i took the wrong direction for this. i will remove this "testing patch" cause i really havent thought about dependecies at all. By: Leif Madsen (lmadsen) 2011-01-06 14:55:35.000-0600 Feature request without a patch. Closing issue for now.