FS#26343 - [jack] automatically change security limits for the 'audio' group
Attached to Project:
Arch Linux
Opened by Bernardo Barros (smoge) - Saturday, 08 October 2011, 18:21 GMT
Last edited by Ray Rashif (schivmeister) - Saturday, 03 December 2011, 18:08 GMT
Opened by Bernardo Barros (smoge) - Saturday, 08 October 2011, 18:21 GMT
Last edited by Ray Rashif (schivmeister) - Saturday, 03 December 2011, 18:08 GMT
|
Details
As recommended by JACK developers[1], the 'jack' and 'jack2'
packages could add a special rule for the 'audio' or
'jackuser' group in `/etc/secutiry/limitis.d/99-audio.conf'
or '/etc/security/limits.d/99-realtime.conf'
@audio - rtprio 99 @audio - memlock unlimited And the a similar post-install message to run those commands: groupadd audio usermod -a -G audio yourUserID Also create a new udev rule `/etc/udev/rules.d/40-hpet-permissions.rules' to allow realtime scheduling: KERNEL=="rtc0", GROUP="audio" KERNEL=="hpet", GROUP="audio" [1] From http://jackaudio.org/linux_rt_config: ----8<--------8<--------8<--------8<--------8<--------8<--------8<--------8<--------8<---- 1. Editing the configuration file If your system has no directory called /etc/security/limits.d then you will need to edit /etc/security/limits.conf. If /etc/security/limits.d does exist on your machine, then you will need to create and edit a file called /etc/security/limits.d/99-realtime.conf. The file must contain (at least) the following two lines: @realtime - rtprio 99 @realtime - memlock unlimited Contrary to a lot of misinformation on the web, there is no reason to include a line here that provides enhanced "niceness" control, which is completely irrelevant for realtime scheduling and low latency audio applications. 2. Creating a "realtime" group As the super-user ("root") run the following commands from a terminal window: groupadd realtime usermod -a -G realtime yourUserID You should substitute your actual user id or "login" for "yourUserID". If you prefer, you can carry out these two steps using the graphical tools that are available under the "System Adminstration" section of your desktop's main menu, but this text-based method is faster and much easier to explain. If you are using a distribution that has already created the group and configured the "limits" file, you will need to determine the name of the group (it is likely called "audio" or "jackuser") and then you can just add yourself to the group with this command (run as the superuser inside a terminal window): usermod -a G theGroupName yourUserId substituting the real names for theGroupName and yourUserId ----8<--------8<--------8<--------8<--------8<--------8<--------8<--------8<--------8<---- |
This task depends upon
Closed by Ray Rashif (schivmeister)
Saturday, 03 December 2011, 18:08 GMT
Reason for closing: Implemented
Saturday, 03 December 2011, 18:08 GMT
Reason for closing: Implemented
http://anonscm.debian.org/gitweb/?p=pkg-multimedia/jack-audio-connection-kit.git;a=blob;f=debian/audio.conf;h=7081b4a0c007b0077b432daf1a286bca08d97916;hb=HEAD
The only way this can be fair is if we move this to a separate 'realtime' group, so only users who need the functionality can opt in. This means for these users they would have to get used to this new group, and not rely on 'audio' anymore for realtime access. The rest continue to use jack normally, possibly with '--no-realtime'.
'limits.d' should be supported by our pam, but can anyone confirm?
Also, should we do this from jack? Realtime is not audio-exclusive, so my opinion is that we do this from, say, pam itself.
Comment out any changes you made to /etc/security/limits.conf or revert it to stock state, then install jack from [testing] and test. You will see that you have to add yourself to the 'realtime' group. You have to do this every time you install a jack package, meaning if you switch from jack to jack2, you will have to re-add users to the 'realtime' group.
A nicer yet less KISS solution (I think) would be to create a separate "realtime-config" package that these jack packages can depend on. The most KISS approach would be to skip this separation of realtime and generic audio, and simply configure the 'audio' group. Without much input/feedback though, I'll keep it this way because I believe normal users should not be forced to use realtime especially since it's related to security.
So, please test and report.