Problems running timidity++ with PulseAudio

Almost any modern soundcard seems not to provide any MIDI playback support, at least not through an hardware synthesizer, with the exclusion of a few Creative Labs cards like the ones based on Emu10k1.

For any other card, the Gentoo ALSA guide suggests to use timidity++, a software synthesizer that takes care of playing the MIDI for you. I took care of it for a while before, I wrote the eselect timidity module exactly one year ago, to allow choosing the patchset to be used.

Today I was looking for cleaning up old versions and seen there was still a bug open that needed to be addressed. While preparing to test a solution, I found one big flaw in the way we let users use timidity at the moment. A flaw that should be addressed as soon as possible.

So, I noticed the flaw by the fact that timidity failed to work with PulseAudio started. Sure enough, it tries to use the default ALSA device, which is the pulse plugin to send audio to PulseAudio. And root is not allowed to use pulseaudio, as it’s not in the pulse-access group.

Let’s take half a step back. root? Yes. We’re leaving users to send MIDI data to a software that runs as root. Do you see the implication? If there was an exploitable vulnerability in timidity, it could allow to compromise the root user.

So here is the problem: we’re not running with the minimal privileges possible, we’re running timidity as root. And this is not good at all. My TODO list now has on its top having timidity work without starting as root. Defining a timidity user to run with, user that you can easily add to pulse-access group to use PulseAudio, user that is not a big deal to compromise at that point.

So expect a new timidity++ revision in tree before night, with some improvements for the ALSA software synthesizer!

Exit mobile version