[PlanetCCRMA] the jack permissions conundrum revisited

Fernando Lopez-Lezcano nando at ccrma.Stanford.EDU
Fri Jul 23 10:20:07 PDT 2010


On Thu, 2010-07-22 at 12:03 -0700, Jeff Sandys wrote:
> I am trying to understand this jack permissions conundrum.  You stated:
> 
> > - Fedora jack1 packages allows users access to realtime
> > scheduling and memory locking only if the user belongs
> > to a particular group (jackuser?).
> 
> I am not sure this is true.  When I load jack into fedora 13 from
> fedora repositories, jackd is in group root and all users have
> execution privileges.

Easy to get confused. It is not the group of jack what matters, it is
the group of the user that runs jack. Jack can be executed by anyone, as
any other binary. But only users that belong to a certain group will be
able to run it with real-time scheduling. 

> >From what I can tell on UbuntuStudio all users can run jack with
> realtime without any special groups.
> 
> What is the security threat of this configuration, is it an esoteric
> problem that no one has figured out how to exploit, or does it open a
> vulnerability that we should really worry about?

If you use the Fedora jack there are no weird security problems (except
that a user that has access to real-time scheduling can hang the machine
at will[*]). 

In the case of Planet CCRMA I enable all users to run with real-time
scheduling and that can lead to potential problems (I have never heard
of an actual problem) in that all programs can access real-time
scheduling. 

> Does running jack in realtime depend on the RT kernel patch or do you
> have the same security issues with the vanilla kernel?

The kernel itself does not matter, vanilla or rt patched have the same
issues. 

> If it is just a matter of creating a jackuser group and changing
> jackd's group wouldn't it be easier to just create an instruction
> sheet or small script for those who are concerned instead of creating
> two versions of jack?

This is done automatically for you when you install jack. 

-- Fernando

[*] a process that accesses real-time scheduling will have to relinquish
the cpu voluntarily for standard processes to be able to run. If it does
not then it can use the cpu forever, hanging the machine as a side
effect. You can have watchdogs for that, etc, etc. 




More information about the PlanetCCRMA mailing list