[PlanetCCRMA] the jack permissions conundrum

Tue May 25 10:05:35 PDT 2010

Niels, speaking purely as a user with a faint bit of admin knowledge (although very little - I am primarily a user), I can agree with you to an extent, however in this case I believe it becomes a lot more of a grey area. So, take this opinion for what it's worth. 

The analogy you used was for networked UPS devices. The problem is that everyone on an admin level has their own networks, differing UPS devices, etc. and blocks the use of that from "regular" users. So, only specific users, specific machines, specific programs should have access to those devices - and yes, this requires a lot of configuration. 

The problem is that the audio applications at this level are not really user specific. Once a person installs the the "music tools" group like the CCRMA package, they are explicitly stating that this is what this computer is going to be used for - all users, all the time. It IS the configuration change. It is not like adding an antispam application to a mail server, or a UPS control application to an application server - it is more the equivalent of creating a mail server, creating a file server, or creating a workstation - it is creating a media workstation. 

As such, the configuration is expected to change to meet the needs of the function of the workstation. 

I see it more as installing an "engineering" package including CAD and FEA, and expecting the user (or admin) to manually have to enable permission to access OpenGL after the capabilities have been installed - it was installed for a reason. 

Like I said, take it for what it's worth. It's just my opinion. 

----- Original Message ----- 
From: "Niels Mayer" <nielsmayer at gmail.com> 
To: "Simon Lewis" <simon.lewis at slnet-online.de> 
Cc: "Fernando Lopez-Lezcano" <nando at ccrma.Stanford.EDU>, planetccrma at ccrma.Stanford.EDU 
Sent: Tuesday, May 25, 2010 12:39:13 PM GMT -05:00 US/Canada Eastern 
Subject: Re: [PlanetCCRMA] the jack permissions conundrum 

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 

_______________________________________________ 
PlanetCCRMA mailing list 
PlanetCCRMA at ccrma.stanford.edu 
http://ccrma-mail.stanford.edu/mailman/listinfo/planetccrma 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cm-mail.stanford.edu/pipermail/planetccrma/attachments/20100525/db7098fa/attachment.html>