[PlanetCCRMA] the jack permissions conundrum

[Fernando Lopez-Lezcano]

On Tue, 2010-05-25 at 19:30 +0200, Simon Lewis wrote:
> Hi Niels
> 
> I guess in a round-about sort way you confirmed the point I was trying
> to make, you need to have a Phd in rt-scheduling or be a kernel
> developer to optimally configure linux for pro audio use. 

Not really, or so I hope. I don't have a PhD in rt-scheduling :-)
> 
> I know too well that there's tons of info and guidance on how to
> configure linux for audio use in the internet - most of it out of
> date, misleading and putting it nicely rubbish. Worst still those
> users who have plucked up the courage to try Linux and in particular
> are interested in multi-media apps soon give up because it is too
> difficult to configure, usually following the advice they found in the
> internet. But that doesn't stop me canvassing Linux every opportunity
> I get...
> 
> The bottom line is; those apps that need rt-scheduling for optimum
> performance should get it automatically from the default installation
> without any additional tweaking.

They do that both on Fedora and Planet CCRMA, see a caveat below. 

> And no that does not mean a security risk. 

(well, yes there is a security risk as Neils points out, how significant
depends on the environment and your tolerance for risk)

The extra configuration that Neils is talking about and that Fedora
needs is adding the users that need to be able to access realtime
scheduling to a particular group. That has to be done manually for each
user that needs access to rt scheduling and memory locking. 

That is the approach that Fedora takes. It does modify the security
configuration of the machine, but that change only affects programs that
are run by users that are part of a particular group. 

Historically (in Planet CCRMA) I have enabled all users access to rt
scheduling and memory locking. 

In some scenarios (hundreds of users) it is not the most practical
solution (although not impossible, of course) to have an rt group. Users
are implicitly "trusted" and workstations are not servers. The risk is
there, of course. I am trying to keep that option open by adding a
separate package that can be installed to enable rt scheduling for all
users. 

What will happen if/when that option is not the default in Planet CCRMA
is that new users will usually never read the instructions and do what
is suggested. They will just install packages blindly and the first
result they will get is that jack will refuse to start and gives an
error that they will not see nor analyze. 

-- Fernando


> Just because PAM allows a program a better ranking in the linux
> scheduler does not mean it can execute suspect code that overwrites
> root owned files and directories. That's two completely different and
> unrelated activities...
> 
> I run my pc with selinux active in enforced modus and it has never
> complained about those apps that are using enhanced rt-scheduling.
> Selinux does complain when I use the kde apps logged in as root - I do
> this occasionally as I am forced to tweak the configure files in
> the /etc directory - especially if the default installation does not
> meet the bottom line criteria I described above.
> 
> >From a users point of view - whatever solution Fernando adopts it
> should not need further tweaking by a super user.
[MUNCH]