Stumped by mod_portaudio permissions issue
I built freeswitch version 1.7.0+git~20150730T192909Z~ab7f83c654~32bit for my ARM-based home server (an NVIDIA Jetson board), with the intention of using mod_portaudio with a wireless USB headset for my main home phone. It works well when running freeswitch directly as root, but when I configured freeswitch to run at system startup, mod_portaudio could no longer find any audio devices. No problem, I thought, it's a simple permissions issue. I am using the example debian init script from the wiki (this is a Jessie install with SysV init rather than systemd). It runs freeswitch as user freeswitch, group daemon using the -u and -g command-line options. So I added "freeswitch" to the audio group, then used sudo to verify that I could play sound files with "aplay" as the freeswitch user. That worked, but it did not solve the mod_portaudio failure. Thinking there must be an issue with portaudio separate from ALSA, I fetched and built the "pa_devs" utility which enumerates and prints the available audio devices. (This is basically what mod_portaudio is doing on startup.) Running as the freeswitch user, that worked too. Hmmmm. I tried running freeswitch from the command line using sudo rather than the -u and -g options, i.e. $ sudo freeswitch /usr/local/freeswitch/bin/freeswitch -nc and that worked as well! Then I started experimenting with -u and -g and discovered that $ /usr/local/freeswitch/bin/freeswitch -nc -u freeswitch allows mod_portaudio to load correctly, whereas $ /usr/local/freeswitch/bin/freeswitch -nc -u freeswitch -g daemon causes mod_portaudio to fail. Can anyone explain what's happening here? In both cases the process UID, GID, EUID, EGID, FUID, and FGID are the same (freeswitch:daemon) as displayed with "ps xao pid,uid,gid,euid,egid,fuid,fgid". Could this be a bug in freeswitch? There are a couple of threads from 2-3 years ago in the archives, where mod_portaudio permissions issues were never resolved and the solution remained a mystery. For the time being I guess this (not using -g) is a workaround, but I'd sure like to understand what is going on. Mark
Anyone? I thought this might elicit some interest from the developers. Is no one using mod_portaudio anymore? Mark Mark Haun [haunma@keteu.org] wrote:
I built freeswitch version 1.7.0+git~20150730T192909Z~ab7f83c654~32bit for my ARM-based home server (an NVIDIA Jetson board), with the intention of using mod_portaudio with a wireless USB headset for my main home phone. It works well when running freeswitch directly as root, but when I configured freeswitch to run at system startup, mod_portaudio could no longer find any audio devices.
No problem, I thought, it's a simple permissions issue. I am using the example debian init script from the wiki (this is a Jessie install with SysV init rather than systemd). It runs freeswitch as user freeswitch, group daemon using the -u and -g command-line options. So I added "freeswitch" to the audio group, then used sudo to verify that I could play sound files with "aplay" as the freeswitch user. That worked, but it did not solve the mod_portaudio failure.
Thinking there must be an issue with portaudio separate from ALSA, I fetched and built the "pa_devs" utility which enumerates and prints the available audio devices. (This is basically what mod_portaudio is doing on startup.) Running as the freeswitch user, that worked too. Hmmmm.
I tried running freeswitch from the command line using sudo rather than the -u and -g options, i.e.
$ sudo freeswitch /usr/local/freeswitch/bin/freeswitch -nc
and that worked as well! Then I started experimenting with -u and -g and discovered that
$ /usr/local/freeswitch/bin/freeswitch -nc -u freeswitch
allows mod_portaudio to load correctly, whereas
$ /usr/local/freeswitch/bin/freeswitch -nc -u freeswitch -g daemon
causes mod_portaudio to fail.
Can anyone explain what's happening here? In both cases the process UID, GID, EUID, EGID, FUID, and FGID are the same (freeswitch:daemon) as displayed with "ps xao pid,uid,gid,euid,egid,fuid,fgid". Could this be a bug in freeswitch? There are a couple of threads from 2-3 years ago in the archives, where mod_portaudio permissions issues were never resolved and the solution remained a mystery.
For the time being I guess this (not using -g) is a workaround, but I'd sure like to understand what is going on.
Mark
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Mark, As no on else has yet been able to offer anything in the way of guidance, here's my $0.02. If you're simply looking to understand what's going on, if you step back and look at your earlier posts, and clear your mind, I think you'll start hearing someone(s) whispering "race condition", "contention", et al. From a metacognitive perspective I'm fairly certain that's what you're running into. Personally, I'd take a look at the source for the modules in question and see if you can't isolate critical sections of code and protect them properly. I would also stress the code - optimize it highly; build it optimized for space, then for speed; load your system to the hilt so the OS starts to swap; etc. And see what shakes out. Might even try running it under Valgrind, or some other, similar tool. Good luck, Larry On Sep 1, 2015 11:44 AM, "Mark Haun" <haunma@keteu.org> wrote:
Anyone? I thought this might elicit some interest from the developers. Is no one using mod_portaudio anymore?
Mark
Mark Haun [haunma@keteu.org] wrote:
I built freeswitch version 1.7.0+git~20150730T192909Z~ab7f83c654~32bit for my ARM-based home server (an NVIDIA Jetson board), with the intention of using mod_portaudio with a wireless USB headset for my main home phone. It works well when running freeswitch directly as root, but when I configured freeswitch to run at system startup, mod_portaudio could no longer find any audio devices.
No problem, I thought, it's a simple permissions issue. I am using the example debian init script from the wiki (this is a Jessie install with SysV init rather than systemd). It runs freeswitch as user freeswitch, group daemon using the -u and -g command-line options. So I added "freeswitch" to the audio group, then used sudo to verify that I could play sound files with "aplay" as the freeswitch user. That worked, but it did not solve the mod_portaudio failure.
Thinking there must be an issue with portaudio separate from ALSA, I fetched and built the "pa_devs" utility which enumerates and prints the available audio devices. (This is basically what mod_portaudio is doing on startup.) Running as the freeswitch user, that worked too. Hmmmm.
I tried running freeswitch from the command line using sudo rather than the -u and -g options, i.e.
$ sudo freeswitch /usr/local/freeswitch/bin/freeswitch -nc
and that worked as well! Then I started experimenting with -u and -g and discovered that
$ /usr/local/freeswitch/bin/freeswitch -nc -u freeswitch
allows mod_portaudio to load correctly, whereas
$ /usr/local/freeswitch/bin/freeswitch -nc -u freeswitch -g daemon
causes mod_portaudio to fail.
Can anyone explain what's happening here? In both cases the process UID, GID, EUID, EGID, FUID, and FGID are the same (freeswitch:daemon) as displayed with "ps xao pid,uid,gid,euid,egid,fuid,fgid". Could this be a bug in freeswitch? There are a couple of threads from 2-3 years ago in the archives, where mod_portaudio permissions issues were never resolved and the solution remained a mystery.
For the time being I guess this (not using -g) is a workaround, but I'd sure like to understand what is going on.
Mark
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Larry Morley [lmorley@neny.cslimits.net] wrote:
if you step back and look at your earlier posts, and clear your mind, I think you'll start hearing someone(s) whispering "race condition", "contention", et al. From a metacognitive perspective I'm fairly certain that's what you're running into.
That is an interesting theory. Unfortunately, with a workaround in hand (run with u but not -g), my motivation to get to the bottom of this is not sufficient to dig in from scratch. Permissions management is a critical part of any system daemon, and this could be the shadow of a bug with security implications. So I had hoped that it would attract more interest from those with pre-existing knowledge of the code. That it has not reduces my confidence in freeswitch somewhat, and makes me wonder how much of it is in a "don't touch that, it's working" state. Then again, I can't complain about the price... Anyway, I hope there is enough of a google trail here for other users to find the thread. Thanks, Mark
If using alsa, did you check the permission of /dev/snd and its children? Mark Haun <haunma@keteu.org> wrote:
Larry Morley [lmorley@neny.cslimits.net] wrote:
if you step back and look at your earlier posts, and clear your mind, I think you'll start hearing someone(s) whispering "race condition", "contention", et al. From a metacognitive perspective I'm fairly certain that's what you're running into.
That is an interesting theory. Unfortunately, with a workaround in hand (run with u but not -g), my motivation to get to the bottom of this is not sufficient to dig in from scratch.
Permissions management is a critical part of any system daemon, and this could be the shadow of a bug with security implications. So I had hoped that it would attract more interest from those with pre-existing knowledge of the code. That it has not reduces my confidence in freeswitch somewhat, and makes me wonder how much of it is in a "don't touch that, it's working" state. Then again, I can't complain about the price...
Anyway, I hope there is enough of a google trail here for other users to find the thread.
Thanks,
Mark
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Your life is like a penny. You're going to lose it. The question is: How do you spend it? John Covici covici@ccs.covici.com
covici@ccs.covici.com [covici@ccs.covici.com] wrote:
If using alsa, did you check the permission of /dev/snd and its children?
Yes. In fact, both alsa operations (aplay) and portaudio enumeration work correctly when running as the freeswitch user. All of this is detailed in my initial post, two or three weeks ago. Mark
For what it's worth, I'm running into this very same issue over 4 years after the original poster. I suspect that leaving off the group option is leaving the process running as group root, which would mimic my attempt at having the service run as user freeswitch/group root, which allows mod_portaudio to function. I've posted here in the mail list, on IRC and in Slack, but the only bite was someone hinting about freeswitch user needing to be in group audio, which it is. This is broken. I've looked at submitting a JIRA on this, but my login doesn't appear to allow it. On Fri, Sep 11, 2015 at 9:45 AM Mark Haun <haunma@keteu.org> wrote:
covici@ccs.covici.com [covici@ccs.covici.com] wrote:
If using alsa, did you check the permission of /dev/snd and its children?
Yes. In fact, both alsa operations (aplay) and portaudio enumeration work correctly when running as the freeswitch user. All of this is detailed in my initial post, two or three weeks ago.
Mark
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Dear Mark, I tell you exactly why. That is less a permission issue. if you open the shell as "root" and type alsamixer you won't be capable to access the soundcard because "root" is not in the 1st) sound group and 2nd) root ha no access to the pulseaudio server This is why I MUST run freeswitch as the user that is currently logged in. mod_alsa doesn't work at all. I didn't get it running, only mod_portaudio.... best, Tamer On 2020-02-02 07:59, Tom Lynn wrote:
For what it's worth, I'm running into this very same issue over 4 years after the original poster. I suspect that leaving off the group option is leaving the process running as group root, which would mimic my attempt at having the service run as user freeswitch/group root, which allows mod_portaudio to function.
I've posted here in the mail list, on IRC and in Slack, but the only bite was someone hinting about freeswitch user needing to be in group audio, which it is. This is broken. I've looked at submitting a JIRA on this, but my login doesn't appear to allow it.
On Fri, Sep 11, 2015 at 9:45 AM Mark Haun <haunma@keteu.org <mailto:haunma@keteu.org>> wrote:
covici@ccs.covici.com <mailto:covici@ccs.covici.com> [covici@ccs.covici.com <mailto:covici@ccs.covici.com>] wrote: > If using alsa, did you check the permission of /dev/snd and its > children?
Yes. In fact, both alsa operations (aplay) and portaudio enumeration work correctly when running as the freeswitch user. All of this is detailed in my initial post, two or three weeks ago.
Mark
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org <mailto:consulting@freeswitch.org> http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org <mailto:FreeSWITCH-users@lists.freeswitch.org> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________
The FreeSWITCH project is sponsored by SignalWire https://signalwire.com Enhance your FreeSWITCH install with disruptive priced SMS and PSTN services. Build your next product on our scalable cloud platform.
Join our online community to chat in real time https://signalwire.community
Professional FreeSWITCH Services sales@freeswitch.com https://freeswitch.com
Official FreeSWITCH Sites https://freeswitch.com/oss https://freeswitch.org/confluence https://cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users https://freeswitch.com
participants (5)
-
covici＠ccs.covici.com
-
Larry Morley
-
Mark Haun
-
Tamer Higazi
-
Tom Lynn