jackd uses -R force, but it means user cannot even run jackd, he does not have permissions. No way to give permissions. Needs to fix jackit to allow jackd to switch on -r mode if setting -R is not possible.
I suppose this PR is obsolete? With the update of audio/jack to 1.9.16 it is well possible to run the jackdbus server as a user via DBUS interface. Please note that the equivalent of Jack realtime support as used in Linux is not compatible with FreeBSD. While jackd can be run at high priority via RC script, threads of Jack clients will not be promoted to high priority.
You can set: sysctl security.bsd.unprivileged_idprio=1 And it will work for regular users aswell. It just comes with a disclaimer, that your apps know what they are doing. Else you can lockup the machine. --HPS
(In reply to Hans Petter Selasky from comment #2) That just allows the user to set _idle_ priority, or am I missing something? That's not very useful for an audio server ;-)
We could add a similar sysctl knob for rtprio. What do you think?
Created attachment 229555 [details] Patch to allow rtprio for regular users
Konstantin, could you quickly review the attached patch to this PR?
(In reply to Hans Petter Selasky from comment #4) That's probably a good idea. I can't think of any downside as long as it's off by default. Regarding its usefulness, I'd have to do some experiments first. I have no experience with promoting whole GUI applications like Ardour to real time. Only promoting Jack does not help much when the clients are still lower priority.
I do not think this is a right way. Enabling the proposed knob instantly allows any non-privileged user to DoS the machine by starving kernel threads. Perhaps a better model, even if still not ideal, is to have a group which would be allowed to do the scheduling mode change, and e.g. make jackd setgid to it. Enabling the group to do mode change probably should be done by a mac module, similar to mac/ntpd. I remember to see similar discussion happens in Linux world some time ago. Do you know what a resolution was? [And if creating mac module, perhaps a knob to enable user to set idle priority should be removed and functionality provided by mac]
(In reply to Konstantin Belousov from comment #8) While I concur that a sysctl knob is a rather coarse setting, its implications really depend on the use case. It's certainly not desirable on a network server or a remotely administrated workstation, but can be a valid option on a single user machine. Just to make it clear, this is not only about jackd server (or jackdbus), but also about running some threads of _all_ Jack client software with realtime priority. That's more than 100 ports (library dependencies). Without the clients, Jack server will either block or miss some audio data. Which is why I'd prefer a setting with at least user granularity over an application centric approach. Something along the lines of login resource limits (see /etc/login.conf) would be sufficient, while maintaining finer-grained control than a sysctl knob. At this level it's more about robustness than security, because a malicious user can overload the system with a single instance of realtime Jack server anyway. Regarding Linux, realtime privileges seem to be given at user level: https://jackaudio.org/faq/linux_rt_config.html The Jack source code indicates that requesting realtime priority is done per thread through the pthread API. I can change that to use the rtprio_thread() call on FreeBSD.
If rtprio is enabled for a group, administrator can add specific trusted user into this group.
(In reply to Konstantin Belousov from comment #10) Ok, that wasn't obvious to me, no objection from my side then. @HPS, what do you think? Are you still interested? If not, I can look into it next week, but I'll probably need some guidance. On a side note, I did some experiments and it _does_ help to run Jack and clients at realtime priority. I still get the occasional underrun when I totally overload the system - but I rarely do parallel builds of firefox and chromium while recording ;-)
I think much boils down to properly implementing priv_check() . --HPS
Created attachment 229680 [details] MAC module for realtime priority group privilege PLEASE NOTE: The attached patch is meant as a progress report, see questions below. I have a working MAC module now, based on 13.0-RELEASE. It has two sysctl knobs, one to enable the MAC policy for RTPRIO and one to specify the privileged group id. For setup, this means loading the kernel module, enable the policy by sysctl knob, add the user to the realtime group. Questions on how to proceed: 1. Scope and naming - I started with a module name of mac_realtime, but I suppose mac_sched would be a better fit for extending its scope in the future? 2. ATM both idle and realtime policy checks go for PRIV_SCHED_RTPRIO, which means members of the realtime group can also set idle priority? 3. What is a good choice for the group id? I would like to add the "realtime" group to ones preinstalled by the system, what about naming / gid collisions? 13.0-RELEASE was easy for me to test, but I can also work on CURRENT or STABLE if needed. Also, it's still missing a man page for the module and and updates to the rtprio man pages.
Yes, the MAC patch looks about right. Please create a review at https://reviews.freebsd.org so that commenting on the patch follows normal procedure. You will need an account there.
Created attachment 229725 [details] MAC module for realtime privilege group.
Sorry for the noise, somehow saved the new attachment when I just wanted to have Firefox complete the description... Just a last update before we take this to https://reviews.freebsd.org: * Renamed the module to "mac_sched", so it can also be used for an idle priority group if needed. * Chose 47 as the group id for now, seems to be unused on Linux and BSDs. My reviews account has been approved, so I will complete the patch with man pages and then see how to upload that - probably this weekend.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=bf2fa8d9d11c9f2ceff09bacc406876fa37096be commit bf2fa8d9d11c9f2ceff09bacc406876fa37096be Author: Florian Walpen <dev@submerge.ch> AuthorDate: 2021-12-04 16:17:29 +0000 Commit: Konstantin Belousov <kib@FreeBSD.org> CommitDate: 2021-12-04 18:19:25 +0000 MAC/priority module for realtime privilege group This is a MAC policy module that grants scheduling privileges based on group membership. Users or processes in the group realtime (gid 47) are allowed to run threads and processes with realtime scheduling priority. For timing-sensitive, low-latency software like audio/jack, running with realtime priority helps to avoid stutter and gaps. PR: 239125 MFC after: 2 weeks Differential revision: https://reviews.freebsd.org/D33191 etc/group | 1 + lib/libc/sys/rtprio.2 | 9 ++- share/man/man4/Makefile | 1 + share/man/man4/mac_priority.4 (new) | 103 +++++++++++++++++++++++++ sys/conf/NOTES | 1 + sys/conf/files | 1 + sys/conf/options | 1 + sys/modules/Makefile | 1 + sys/modules/mac_priority/Makefile (new) | 6 ++ sys/security/mac_priority/mac_priority.c (new) | 68 ++++++++++++++++ sys/sys/conf.h | 1 + usr.sbin/rtprio/rtprio.1 | 6 +- 12 files changed, 196 insertions(+), 3 deletions(-)
A commit in branch stable/13 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=984b9d89f8396ef53af0ceddfbae549a8db3589e commit 984b9d89f8396ef53af0ceddfbae549a8db3589e Author: Florian Walpen <dev@submerge.ch> AuthorDate: 2021-12-04 16:17:29 +0000 Commit: Konstantin Belousov <kib@FreeBSD.org> CommitDate: 2021-12-19 02:42:51 +0000 MAC/priority module for realtime privilege group PR: 239125 (cherry picked from commit bf2fa8d9d11c9f2ceff09bacc406876fa37096be) etc/group | 1 + lib/libc/sys/rtprio.2 | 9 ++- share/man/man4/Makefile | 1 + share/man/man4/mac_priority.4 (new) | 103 +++++++++++++++++++++++++ sys/conf/NOTES | 1 + sys/conf/files | 1 + sys/conf/options | 1 + sys/modules/Makefile | 1 + sys/modules/mac_priority/Makefile (new) | 6 ++ sys/security/mac_priority/mac_priority.c (new) | 68 ++++++++++++++++ sys/sys/conf.h | 1 + usr.sbin/rtprio/rtprio.1 | 6 +- 12 files changed, 196 insertions(+), 3 deletions(-)
Can we close this bug report? FreeBSD 13.1 is out now, it includes the mac_priority kernel module that allows regular users to run processes at realtime priority. For starters there's some info and pointers in my FreeBSD Audio and Jack notes: https://github.com/0EVSG/freebsd_jack_notes#realtime-priority
Assign to committer who resolved.