Bug 426629 - asterisk fails to load the zaptel channel
asterisk fails to load the zaptel channel
Product: Fedora
Classification: Fedora
Component: asterisk (Show other bugs)
All Linux
low Severity medium
: ---
: ---
Assigned To: Jeffrey C. Ollie
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2007-12-23 04:39 EST by Thomas Sailer
Modified: 2008-07-05 17:27 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-07-05 17:27:18 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Thomas Sailer 2007-12-23 04:39:37 EST
Description of problem:
asterisk complains that it does not have permissions to open devices 
under /dev/zap/*, and thus fails to load the zaptel channel

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. service asterisk start
2. look under /var/log/asterisk/messages
Actual results:
[Dec 23 09:26:03] WARNING[17563] chan_zap.c: Unable to 
open '/dev/zap/channel': Permission denied
[Dec 23 09:26:03] ERROR[17563] chan_zap.c: Unable to open channel 1: 
Permission denied
here = 0, tmp->channel = 1, channel = 1
[Dec 23 09:26:03] ERROR[17563] chan_zap.c: Unable to register channel '1'

Expected results:
x*CLI> zap show channels
   Chan Extension  Context         Language   MOH Interpret
 pseudo            zapincoming     de         default
      1            sailerincoming  de         default
      4            zapincoming     de         default

Additional info:
asterisk starts as user root group root, but is instructed (via command line 
options) to setuid/setgid to user asterisk group asterisk. The zaptel devices 
are user zaptel group zaptel, with permissions rw-rw----. Now the intention 
was to add group zaptel as supplemental group to group asterisk. This cannot 
currently work however, since asterisk does, when switching users/groups, 
setgroups(0, NULL), thus dropping all supplemental groups.

Ways to fix:
1. patch asterisk to honour supplemental groups
2. add acl's to zaptel devices for group asterisk (or user asterisk)
3. have one group telephony instead of separate groups asterisk, zaptel

1 is probably the nicest.
Comment 1 Thomas Sailer 2007-12-23 04:55:12 EST
Actually, asterisk does not need to be patched, it already does that if you 
_do not_ supply the -G argument. So I suggest you remove AST_GROUP from the 
initscript / sysconfig file
Comment 2 Tom Hughes 2008-02-01 09:12:22 EST
I ran into this as well - zaptel was added (by something, not sure if it was
asterisk or zaptel) to the supplementary groups for asterisk, but that is then
ignored by asterisk.

Basically, asterisk has some weird logic where if you specify a user and a group
when starting it then it runs with exactly those permissions and discards all
supplementary groups. If you only specify a user then it takes that user's
default group and all that user's supplementary groups (including zaptel in this

My solution was the same as yours - removing the AST_GROUP setting from the
config file.
Comment 3 Fedora Update System 2008-02-19 08:59:21 EST
asterisk-1.4.18-1.fc8 has been submitted as an update for Fedora 8
Comment 4 Fedora Update System 2008-02-19 10:55:44 EST
asterisk-1.4.18-1.fc7 has been submitted as an update for Fedora 7
Comment 5 Fedora Update System 2008-02-20 21:53:26 EST
asterisk-1.4.18-1.fc8 has been pushed to the Fedora 8 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update asterisk'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F8/FEDORA-2008-1854
Comment 6 Robert Scheck 2008-07-05 14:39:52 EDT
The fix works for me, also added positive charma.

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