Summary:	ASTERISK-04612: 'restart' fails with asterisk -U
Reporter:	Tzafrir Cohen (tzafrir)	Labels:
Date Opened:	2005-07-18 13:54:32	Date Closed:	2008-01-15 15:44:57.000-0600
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) asterisk_restart_noroot.diff.txt
Description:	When asterisk is started with -U username, it will crash when trying to restart. restart is basicaly exec-ing the original command. However by the time asterisk restarts it no longer has priviliges for setuid, setgid and set_priority . As a result it will crash when it attempts to run the first of those three. Solution: simply don't do either of those. They are still in effect. My current solution is to pass this through the environment. An alternative approach is to manipulate argv, but I believe it is more complicated. ****** ADDITIONAL INFORMATION ****** Attached is a patch to 1.0.9 . I don't have time to test it with HEAD right now, and hence no [patch] prefix.
Comments:	By: Russell Bryant (russell) 2005-07-18 13:59:33 Did you purposely say "No" to the question about your disclaimer? By: Clod Patry (junky) 2005-07-19 11:41:15 We need patch for HEAD, and we can't use your patch, cause you have no disclaimer on file. By: Tzafrir Cohen (tzafrir) 2005-07-19 12:57:09 patch seems to apply to HEAD. I can't test a build of it yet. However: I'd just like to verify that this is still a problem with HEAD: if you have asterisk running as a user, will it successfully restart after a 'restart now' CLI command? By: Michael Jerris (mikej) 2005-07-19 13:36:45 we need to know if you have a disclaimer. By: Tzafrir Cohen (tzafrir) 2005-07-19 19:35:50 Private communication is not enough, aparantly. So here it is again: I wrote "No" and "no" means "no". Rationale was clarified in private communication. Mean while, noone has commented on the bug report itself (solution aside). By: Clod Patry (junky) 2005-07-19 21:50:31 Not having a disclaimer will result, none will look at your patch. By: Tzafrir Cohen (tzafrir) 2005-07-19 22:15:27 Let's run this again: Me: this bug has no [patch] prefix to it. Is it reproducable. There is a patch but I don't have the time to clean it right now. Reply 1: is the "no" a real "no" for the disclaimer? Reply 2: does the patch work for HEAD? Where is the disclaimer? Me: seems to apply to HEAD. Untested. But is the problem reproduced in HEAD? Reply 3: we need to know if you have a disclaimer. [in private communication: I can't disclaim it right now. I will] Me: No means no. reproducable in HEAD? [bug is easy to reproduce] Reply 4: Not having a disclaimer will result, none will look at your patch. So, current reply: please ignore the patch. s/patch//g in this report for a moment.  Hmm.. I think I'll try that method. By: Tilghman Lesher (tilghman) 2005-07-19 22:54:11 Patch removed with consent of poster, due to no disclaimer.  Patch can be reuploaded when a disclaimer is on file. By: Michael Jerris (mikej) 2005-07-26 21:27:51 any update? By: Clod Patry (junky) 2005-07-28 00:24:29 debian:/etc/asterisk# asterisk -Ucli Unable to open pid file '/var/run//asterisk.pid': Permission denied debian:/etc/asterisk# ls -l /var/run//asterisk.pid ls: /var/run//asterisk.pid: No such file or directory debian:/etc/asterisk# By: Tzafrir Cohen (tzafrir) 2005-07-28 01:11:01 What exactly is the username here? 'cli' ? Anyway, when running Asterisk as a user you would normally set something like: astrundir => /var/run/asterisk astlogdir => /var/log/asterisk in asterisk.conf, and give the Asterisk user write permissions to those directories. Another thing to consider when touching that part of the code: what if someone wants to run Asterisk in a chroot jail? Currently this won't work, I believe. By: Michael Jerris (mikej) 2005-08-09 13:11:25 This is not major, as there is a workaround. By: Tzafrir Cohen (tzafrir) 2005-08-10 15:01:27 The workaround presented here is not relevant to the bug itself. It is a work around a simpler problem (a simpler file permissions issue). Here the issue is the permissions of the Asterisk process itself. Asterisk needs some permissions at start-time. Obtaining those permissions requires root. On "restart" asterisk re-execs and is quite upset when it finds out it fails to have enough permissions to ask for extra priviliges (even though it actually doesn't need to). By: Michael Jerris (mikej) 2005-08-10 15:04:19 The workaround is to run as root.  Not saying this is not a bug, but just that it is not Major as defined in the bug guidelines. By: Tzafrir Cohen (tzafrir) 2005-08-11 11:43:33 Resubmitting the patch to solve the problem. Patch is disclaimed. By: Kevin P. Fleming (kpfleming) 2005-08-22 21:35:36 Committed to CVS HEAD, thanks! By: Digium Subversion (svnbot) 2008-01-15 15:44:57.000-0600 Repository: asterisk Revision: 6369 U   trunk/asterisk.c ------------------------------------------------------------------------ r6369 | kpfleming | 2008-01-15 15:44:57 -0600 (Tue, 15 Jan 2008) | 2 lines don't try to change run priority, EUID or EGID on restart if they were already set (issue ASTERISK-4612 with minor mods) ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=6369