[PlanetCCRMA] the jack permissions conundrum

Tue May 25 10:30:31 PDT 2010

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.

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. 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...

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.

Simon

Am 25.05.2010 18:39, schrieb 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
>
>    

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ccrma-mail.stanford.edu/pipermail/planetccrma/attachments/20100525/9b43bc10/attachment.html 