[PlanetCCRMA] Fwd: jack2

[Fernando Lopez-Lezcano]

On Sun, 2010-04-18 at 16:59 -0700, Niels Mayer wrote:
> I was wondering what this message meant for CCRMA jack users.
> Currently I'm at
> jack-audio-connection-kit-1.9.4-1.fc12.ccrma.x86_64 ... is that
> considered "jack2" ?? (I don't see a "jack2" package otherwise).

That's jack2. 0.xxx is jack1, 1.9.x is what is going to become jack2. 

> > Is there anyone who would object this change? Anyone not happy with
> jack2?
> 
> Not an objection, just a concern. Orcan's message included this, which
> reminded me of a security issue I wanted to address:
> 
> 
> ... From: Adrian Knoth @ Debian:
>         * Realtime permissions: our jackd package creates the file
>            /etc/security/limits.d/audio.conf with the following
>         content:
>         
>            @audio   -  rtprio     95
>            @audio   -  memlock    unlimited
> 
> CCRMA's jack-audio-connection-kit installs the following
> in /etc/security/limits.conf
>         ## Automatically appended by the Planet CCRMA
>         jack-audio-connection-kit
>         * - rtprio 99
>         * - memlock 4194304
>         * - nice -10
>  
> Doesn't this mean (due to wildcards) that any app that asked for those
> privs would get them?

This is not related to applications but to users. It means any user can
run apps with realtime priorities. 

> This seems like an unadvertized security ramification for anybody that
> happened to install (not even use) jack-audio-connection-kit.

This only happens if you install the Planet CCRMA Jack. Planet CCRMA
users generally install it if they need access to a low latency kernel,
the latest Jack and associated apps for using them with the best
performance and that implies rt access. 

> Isn't the proper Fedora/Linux/Un*x way to add users needing those
> privs to a group like 'rtkit' 'jackuser' or 'audio' as is done in
> debian??

That is the way it is currently done in the Fedora jack package (the
user has to belong to the "jackuser" group). 

In the case of Planet CCRMA my intention all these years has been to
have a the best possible performing environment that works out of the
box without the user having to do any configuration (or as little as
possible). 

> Per LIMITS.CONF(5):
>               The syntax of the lines is as follows:
>                <domain> <type> <item> <value>
>                The fields listed above should be filled as follows:
>                <domain>
>                    ·   a username
>                    ·   a groupname, with @group syntax. This should
>         not be confused
>                        with netgroups.
>                    ·   the wildcard *, for default entry.
> 
> 
> The current settings make those limits the "default entry."  (I'm
> wondering if some other process accidentally achieving too much
> realtime prio caused the priority deadlock described
> here:http://old.nabble.com/help-w--qjackctl-locks-up-X-GUI-(perhaps-caused-by-dbus-or-kernel-2.6.32.11-99.fc12.x86_64)-to28221239.html )

I don't think we know why that was happening. 

In terms of "security", realtime access allows users that have the
permission to run apps SCHED_FIFO to actually hang a machine (if there
is no watchdog process running). A program that enters into an infinite
loop, runs in the realtime scheduler and does not relinquish the cpu
will keep running forever and not allow any other processes access to
the cpu (unless they are also realtime and with higher priority). 

a) If you are the sole user of the computer in question that is not a
problem (if you hang the machine, well, it is just you doing it to
yourself :-). 

b) If the computer is installed in a place so that that several users
can do audio work (as, for example, at ccrma) then obviously you trust
those users to not do the wrong thing, at least not on purpose (a buggy
program could do that, for example). 

c) If the computer is completely general purpose, has many users, and
you don't trust your users.... well, you should not be running realtime
apps if you want absolute reliability. 

A middle ground is possible and that is the approach of other distros,
including Fedora. Users have to be specifically made part of a group to
be able to access realtime scheduling. So far I have considered a Planet
CCRMA workstation to belong to categories a) or b). Universal access
could be part of an additional package, for example. So far I have not
see the need to do that. 

-- Fernando