<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
<font face="sans-serif"><small>Hi Niels<br>
<br>
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. <br>
<br>
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...<br>
<br>
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. And no that does not mean a security
risk. 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...<br>
<br>
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.<br>
<br>
>From a users point of view - whatever solution Fernando adopts it
should not need further tweaking by a super user.<br>
<br>
<br>
Simon<br>
<br>
<br>
<br>
<br>
<br>
Am 25.05.2010 18:39, schrieb Niels Mayer:</small></font>
<blockquote
cite="mid:AANLkTileQJQ1_cixMh4_2BmjpZ5Y5cq7-PJfF1CNGFvv@mail.gmail.com"
type="cite">
<pre wrap="">On Mon, May 24, 2010 at 9:08 PM, Simon Lewis
<a class="moz-txt-link-rfc2396E" href="mailto:simon.lewis@slnet-online.de"><simon.lewis@slnet-online.de></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
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: <a class="moz-txt-link-freetext" href="http://old.nabble.com/Re:-Fwd:-jack2-p28288652.html">http://old.nabble.com/Re:-Fwd:-jack2-p28288652.html</a>
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:
</pre>
<blockquote type="cite">
<pre wrap="">## Automatically appended by jack-audio-connection-kit
@pulse-rt - rtprio 20
@pulse-rt - nice -20
</pre>
</blockquote>
<pre wrap="">
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.
<a class="moz-txt-link-freetext" href="http://en.wikipedia.org/wiki/Priority_inversion">http://en.wikipedia.org/wiki/Priority_inversion</a>
-- Niels
<a class="moz-txt-link-freetext" href="http://nielsmayer.com">http://nielsmayer.com</a>
</pre>
</blockquote>
<br>
</body>
</html>