Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

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
Task Type Feature Request
Category Packages: Extra
Status Closed
Assigned To Ray Rashif (schivmeister)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

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
Comment by Bernardo Barros (smoge) - Sunday, 09 October 2011, 05:22 GMT
Debian and Fedora also use the limits.d/audio.conf approach, so the user do not have to manually configure those limits:

http://anonscm.debian.org/gitweb/?p=pkg-multimedia/jack-audio-connection-kit.git;a=blob;f=debian/audio.conf;h=7081b4a0c007b0077b432daf1a286bca08d97916;hb=HEAD

Comment by Ray Rashif (schivmeister) - Sunday, 09 October 2011, 05:37 GMT
  • Field changed: Summary (JACK package should automatically change security limits for the 'audio' group → [jack] automatically change security limits for the 'audio' group)
  • Field changed: Status (Unconfirmed → Assigned)
  • Field changed: Severity (High → Medium)
  • Task assigned to Ray Rashif (schivmeister)
This is all good, but not every jack user needs realtime. There are even conflicting opinions (upstream) on what those numbers should be.

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 by Ray Rashif (schivmeister) - Thursday, 13 October 2011, 20:37 GMT
We'll do this from jack as it's the only one I know that uses realtime scheduling from a userland perspective - no need to invade PAM. Latest PAM should support limits.d configuration. I've also decided to not let any kind of automation take place for the scheduling, i.e users who install jack will not get to use realtime scheduling "out-of-the-box". The 'audio' group is more generic and should be left at that. We will rely on a more specific group here, 'realtime'.

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.
Comment by Ray Rashif (schivmeister) - Saturday, 05 November 2011, 07:36 GMT
  • Field changed: Status (Assigned → Waiting on Response)
The packages have been lying dormant in [testing] for over 2 weeks. I'll move them as-is if there are no further opinions.
Comment by Ray Rashif (schivmeister) - Wednesday, 23 November 2011, 16:23 GMT
Went with the KISS approach in the end. Will move from testing this time within a couple days.
Comment by Ray Rashif (schivmeister) - Saturday, 03 December 2011, 17:51 GMT
Thanks for testing..forgot to update the hpet rules.

Loading...