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
We have the same problem with 1.8.18.0 version. Please fix it!!!
I have hit this same problem. Please, fix it. It's a security bug, because Asterisk runs as root by default.
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
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...
Patch work perfectly, this issue can be a potential security problem.
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
(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.
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.
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).
This message is a reminder that EPEL 6 is nearing its end of life. Fedora will stop maintaining and issuing updates for EPEL 6 on 2020-11-30. It is our policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of 'el6'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later EPEL version. Thank you for reporting this issue and we are sorry that we were not able to fix it before EPEL 6 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above.
EPEL el6 changed to end-of-life (EOL) status on 2020-11-30. EPEL el6 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of EPEL please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.