[PlanetCCRMA] the jack permissions conundrum

[Niels Mayer]

On Mon, May 24, 2010 at 9:08 PM, Simon Lewis
<simon.lewis at slnet-online.de> wrote:
> Since the user should not need to manually edit conf files I would suggest to give all users rt-sscheduling as is the case now.

Most other packages in fedora require some configuration before they
can be used. The issue is that just installing a package shouldn't
significantly change the configuration of your machine (esp security)
without some explicit notification of what's being done.

Unfortunately, that's exactly what the CCRMA jack package does,
currently: http://old.nabble.com/Re:-Fwd:-jack2-p28288652.html

Someone deciding to install all packages in some group like "music
tools" shouldn't be surprised with a system that behaves totally
differently unless they've explicitly enabled use of that tool.

This is really no different than any other package in fedora. For
example, I don't install "nut" (network ups tools) and expect it to
find and configure my UPS devices -- it needs to be explicitly setup;
devices that are normally secured from access need to be added to
groups, chkconfig needs to be enabled for the daemon, etc. Likewise I
shoudn't install Jack and have it significantly change the
configuration of my machine -- without explicitly "enabling" them...

The issue is the "wildcards" (*) apply not only to all real users, but
also "daemon" users. And apply to any program on the system rather
than just the ones you want to give extra privileges to....

## Automatically appended by the Planet CCRMA jack-audio-connection-kit
* - rtprio 99
* - memlock 4194304
* - nice -10

The wildcards here mean that these limits can be granted to any
program and any user that requests them. That includes daemon
processes (e.g. network services) that are meant to run with
constrained privileges and access, yet could potentially end up
allowing your machine to be "locked up" remotely, or even worse, flood
a network or router with packets (and not be stoppable until you hit
the power switch on the computer). Note that most programs don't
request these priorities so it's not like formerly safe programs
become "dangerous" -- however, programs that do allow altering
priorities can become problematic (e.g. pulseaudio). Or you can simply
leave the system quietly setup with wildcards, and at sometime later,
introduce a single "rogue" program that takes advantage of the
priority escalation (imagine if java applets and flash programs could
request high priority and nice levels: you could do some serious
damage just by browsing the wrong site -- like setup a giant
distributed denial of service attack against a website, company, or
government).

Further, these wildcards could end up matching and overriding other
limits set for other programs. For example instead of running at
priority 20 and nice -20 per:
> ## Automatically appended by jack-audio-connection-kit
> @pulse-rt - rtprio 20
> @pulse-rt - nice -20

The wildcards could override the above pulseaudio settings, and end up
mathcing the "*" and get priority 99 and nice -10.

 Which means that, for example, your pulseaudio RT could end up
running at the exact same priority as Jack RT -- which is a good way
to get a deadlock. Perhaps the  jack lockups I saw related to this are
because jack and pulseaudio were running at the same priority (due to
the wildcards), and when jack signals pulseaudio to shut itself off
via dbus, they deadlock.

http://en.wikipedia.org/wiki/Priority_inversion

-- Niels
http://nielsmayer.com