<html><head><style type='text/css'>p { margin: 0; }</style></head><body><div style='font-family: Arial; font-size: 12pt; color: #000000'>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.<br><br>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.<br><br>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.<br><br>As such, the configuration is expected to change to meet the needs of the function of the workstation.<br><br>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.<br><br>Like I said, take it for what it's worth. It's just my opinion.<br><br><br><br>----- Original Message -----<br>From: "Niels Mayer" <nielsmayer@gmail.com><br>To: "Simon Lewis" <simon.lewis@slnet-online.de><br>Cc: "Fernando Lopez-Lezcano" <nando@ccrma.Stanford.EDU>, planetccrma@ccrma.Stanford.EDU<br>Sent: Tuesday, May 25, 2010 12:39:13 PM GMT -05:00 US/Canada Eastern<br>Subject: Re: [PlanetCCRMA] the jack permissions conundrum<br><br>On Mon, May 24, 2010 at 9:08 PM, Simon Lewis<br><simon.lewis@slnet-online.de> wrote:<br>> 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.<br><br>Most other packages in fedora require some configuration before they<br>can be used. The issue is that just installing a package shouldn't<br>significantly change the configuration of your machine (esp security)<br>without some explicit notification of what's being done.<br><br>Unfortunately, that's exactly what the CCRMA jack package does,<br>currently: http://old.nabble.com/Re:-Fwd:-jack2-p28288652.html<br><br>Someone deciding to install all packages in some group like "music<br>tools" shouldn't be surprised with a system that behaves totally<br>differently unless they've explicitly enabled use of that tool.<br><br>This is really no different than any other package in fedora. For<br>example, I don't install "nut" (network ups tools) and expect it to<br>find and configure my UPS devices -- it needs to be explicitly setup;<br>devices that are normally secured from access need to be added to<br>groups, chkconfig needs to be enabled for the daemon, etc. Likewise I<br>shoudn't install Jack and have it significantly change the<br>configuration of my machine -- without explicitly "enabling" them...<br><br>The issue is the "wildcards" (*) apply not only to all real users, but<br>also "daemon" users. And apply to any program on the system rather<br>than just the ones you want to give extra privileges to....<br><br>## Automatically appended by the Planet CCRMA jack-audio-connection-kit<br>* - rtprio 99<br>* - memlock 4194304<br>* - nice -10<br><br>The wildcards here mean that these limits can be granted to any<br>program and any user that requests them. That includes daemon<br>processes (e.g. network services) that are meant to run with<br>constrained privileges and access, yet could potentially end up<br>allowing your machine to be "locked up" remotely, or even worse, flood<br>a network or router with packets (and not be stoppable until you hit<br>the power switch on the computer). Note that most programs don't<br>request these priorities so it's not like formerly safe programs<br>become "dangerous" -- however, programs that do allow altering<br>priorities can become problematic (e.g. pulseaudio). Or you can simply<br>leave the system quietly setup with wildcards, and at sometime later,<br>introduce a single "rogue" program that takes advantage of the<br>priority escalation (imagine if java applets and flash programs could<br>request high priority and nice levels: you could do some serious<br>damage just by browsing the wrong site -- like setup a giant<br>distributed denial of service attack against a website, company, or<br>government).<br><br>Further, these wildcards could end up matching and overriding other<br>limits set for other programs. For example instead of running at<br>priority 20 and nice -20 per:<br>> ## Automatically appended by jack-audio-connection-kit<br>> @pulse-rt - rtprio 20<br>> @pulse-rt - nice -20<br><br>The wildcards could override the above pulseaudio settings, and end up<br>mathcing the "*" and get priority 99 and nice -10.<br><br> Which means that, for example, your pulseaudio RT could end up<br>running at the exact same priority as Jack RT -- which is a good way<br>to get a deadlock. Perhaps the jack lockups I saw related to this are<br>because jack and pulseaudio were running at the same priority (due to<br>the wildcards), and when jack signals pulseaudio to shut itself off<br>via dbus, they deadlock.<br><br>http://en.wikipedia.org/wiki/Priority_inversion<br><br>-- Niels<br>http://nielsmayer.com<br><br>_______________________________________________<br>PlanetCCRMA mailing list<br>PlanetCCRMA@ccrma.stanford.edu<br>http://ccrma-mail.stanford.edu/mailman/listinfo/planetccrma<br></div></body></html>