Pulseaudio strikes again!

[David A. De Graaf]

On Tue, Jun 26, 2012 at 08:24:05PM -0500, Mikkel L. Ellertson wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 06/26/2012 02:22 PM, David A. De Graaf wrote:
> > Does anyone know how to allow root and users other than me to use the
> > sound system?
> >
> > Ever since pulseaudio was introduced in Fedora 8 and Mr. Lennart
> > Poettering inflicted his peculiar ideas of security on us, the default
> > installation hasn't worked properly, despite many BZ's and copious
> > complaints! Specifically, pulseaudio invents the "seat" and only the
> > one person in the "seat" can use the sound system. This precludes
> > having root, or anyone else, from generating sounds - presumably it's a
> > security risk. Bosh!
> Well, that depends on if you have a microphone attached to your
> system, and consider allowing a remote user to listen to what is
> going on by your computer a security risk.

There's the microphone, the camera and the loudspeaker.  Surely
software can distinguish between them.  In my case, at home, I'm
really not worried about secret spying.  And if it did occur, I'd
handle the problem with social intervention, not software blockage.
What annoys me is the inability for anyone on the system to produce
sounds without arbitrary restrictions.

> >
> > A simple workaround was found - remove the alsa-plugins-pulseaudio
> > package, and edit /etc/group, adding everyone on the system to the
> > audio group (what a nutty idea). That removed the restrictions and
> > restored sanity. Root could even generate a login tune via the
> > /etc/rc.d/rc.local script, before anyone had logged on.
> >
> > With F17, this escape hatch has been removed.
> > With the alsa-plugins-pulseaudio package absent, a simple command to
> > play a sound yields a core dump:
> >
> > $ play /usr/share/sounds/KDE-Sys-Log-In.ogg
> > dsp_protocol_open_node(): Could not open pcm device file
> /dev/dsptask/pcm2
> > Segmentation fault (core dumped)
> >
> > The pcm device file is, indeed, absent from the file system.
> > In fact, no sounds whatever can be generated by any of the standard
> > methods I use. (Except that Windows running inside VirtualBox seems
> > able to manage it.)
> It sounds like the snd_pcm module did not get loaded.

Now that sounds like a clue.  Can you be more specific?
I can find no package with "snd_pcm" in its name.

Also, did I mention that sound, and the
  yum erase alsa-plugins-pulseaudio
workaround, works perfectly on an i386 netbook.  On that netbook
the file   /dev/dsptask/pcm2   is also missing; yet the 'play' program
works anyway.
It suggests a bug in the x86_64 version of 'play', except that all the
other sound-producing programs also don't work.  Therefore, I deduce
it's the fault of pulseaudio...

> >
> > To get any sound at all, I've had to reinstall the
> > alsa-plugins-pulseaudio package, but this allows only me to generate
> > sound and destroys my crontab-simulated grandfather clock, among other
> > things.
> >
> > On an i386 netbook, F17 sound works fine, as it always has, with the
> > alsa-plugins-pulseaudio package removed. The play program doesn't
> > complain about the absence of /dev/dsptask/pcm2, but just plays the
> > sound.
> >
> > What new magic incantation is now required that I may be permitted
> > to use my x86_64 sound system fully?
> >
> You may want to look into running PA as a system daemon instead of a
> user daemon.

I have done so, and it didn't work.  Specifically, I put these
commands into /etc/rc.d/rc.local:
  # Start the pulseaudio daemon
  /usr/bin/pkill -9 pulseaudio
  /usr/bin/pulseaudio --kill
  sleep 1
  echo "/usr/bin/pulseaudio -D --system --log-target=syslog"
  /usr/bin/pulseaudio -D --system --log-target=syslog
  /usr/bin/play /usr/share/sounds/KDE-Im-Phone-Ring.ogg

Upon rebooting, no sound was produced, but a pulseaudio daemon was
found running with the --system option.  Neither I nor root could produce
any sound.  The 'play' command ran for a time commensurate with its
usual running time, but no sound emanated from the speakers.

Neither  'pulseaudio --kill' nor  'pkill pulseaudio'  were able to
stop the daemon, either as root or as dad.  root running 'kill -9 <pid>'
did kill it.  With it gone, I could once again generate sound, but root
could not.

Perhaps I misunderstand the correct way to start a "system daemon" of
pulseaudio.  I did also edit /etc/group, adding root and dad to groups
audio, pulse, pulse-access just for good measure.

Reading 'man pulseaudio' tells me the --system option is not
recommended.  Perhaps the consequences are so dire and
world-threatening that the developer has made it inoperative.
It tells us that a special configuration is needed, but provides no
clue what that may be.

-- 
        David A. De Graaf    DATIX, Inc.    Hendersonville, NC
        dad at datix.us         www.datix.us

We have enough youth, how about a fountain of SMART?