Bug 833460 - asterisk does not start as user defined in AST_USER
asterisk does not start as user defined in AST_USER
Status: NEW
Product: Fedora EPEL
Classification: Fedora
Component: asterisk (Show other bugs)
el6
All Linux
unspecified Severity low
: ---
: ---
Assigned To: Jared Smith
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-06-19 10:00 EDT by Guillermo
Modified: 2017-03-15 11:01 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
patch to use ASTARGS to define -U and -G options (433 bytes, application/octet-stream)
2012-06-19 10:00 EDT, Guillermo
no flags Details
Patch to fix init script (721 bytes, patch)
2013-05-21 13:15 EDT, Juan Orti
no flags Details | Diff

  None (edit)
Description Guillermo 2012-06-19 10:00:11 EDT
Created attachment 592967 [details]
patch to use ASTARGS to define -U and -G options

Description of problem:
The included /etc/init.d/asterisk script uses the variable AST_ARGS instead of ASTARGS at two lines.

Version-Release number of selected component (if applicable):
asterisk.x86_64                           1.8.12.2-1.el6                @epel

How reproducible:
always

Steps to Reproduce:
1. define AST_USER
2. /etc/init.d/asterisk start
3.
  
Actual results:
runs as root

Expected results:
run as user defined in AST_USER

Additional info:
possible patch attached
Comment 1 Masvoz 2012-12-11 11:15:27 EST
We have the same problem with 1.8.18.0 version.

Please fix it!!!
Comment 2 Juan Orti 2013-05-21 13:13:25 EDT
I have hit this same problem. Please, fix it. It's a security bug, because Asterisk runs as root by default.
Comment 3 Juan Orti 2013-05-21 13:15:12 EDT
Created attachment 751328 [details]
Patch to fix init script

This patch is the same as the previous one, but applied against the EPEL git branch
Comment 4 LightDot 2013-09-07 04:09:40 EDT
Still present in asterisk-1.8.20.0-1.el6.

I don't undersand why something so simple isn't fixed after more than a year...
Comment 5 Grummfy 2014-01-20 07:49:55 EST
Patch work perfectly, this issue can be a potential security problem.
Comment 6 Phil Anderson 2014-03-29 21:47:17 EDT
Note that this patch will likely break existing installs as there will be files inside /var owned by root which asterisk will no longer be able to access:
/var/lib/asterisk
/var/log/asterisk
/var/spool/asterisk
Comment 7 Dave Miller 2014-05-06 09:05:59 EDT
(In reply to Phil Anderson from comment #6)
> Note that this patch will likely break existing installs as there will be
> files inside /var owned by root which asterisk will no longer be able to
> access:

Best fix for this is probably to have the initscript reset the permissions to work for that user as part of the startup process.  I could swear an older version of asterisk did exactly this in its initscript, but the current one doesn't seem to.
Comment 8 Dave Miller 2014-05-06 09:38:07 EDT
For purposes of setting permissions, $AST_GROUP should be assumed to be the primary group of $AST_USER if it's not otherwise specified.

As best I can tell, nothing in /var/lib/asterisk should be writable to the asterisk user.  The keys directory should be readable *only* to the asterisk user though (root:asterisk 750, files root:asterisk 640)

The following directories should be recursively owned by and writable to the asterisk user:
/var/log/asterisk
/var/spool/asterisk
/var/run/asterisk

/etc/asterisk/voicemail.conf needs to be writable by asterisk for users to be able to change their passwords.

I seem to recall that there's a few other files in /etc/asterisk that need to be written to by asterisk, but I don't recall what they are offhand.

It looks like asterisk actually sets the correct permissions on everything already, so the cleanup should only have to set owner and group, and not have to worry about permissions.
Comment 9 Dave Miller 2014-05-06 09:53:41 EDT
FWIW, the logrotate.d script provided by this package assumes that it needs to run as the asterisk user without looking in /etc/sysconfig/asterisk to find out, and the log rotation fails because of this (asterisk never reopens the new log file, and will continue logging to the one that got deleted, which means your future logs all go byebye as soon as they get rotated from the view of the admin, and it will continually use up disk space without a corresponding directory entry to locate it until you restart asterisk or do a logger reload).

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