[arch-dev-public] Realtime group and possible helper package
Hello folks I am looking to provide support for a 'realtime' group, for use with not just audio/video but any other/future applications of real-time. The 'audio' group will "remain" for backward compatibility, indefinitely. I can therefore either create the new group or users have to do it. If I choose to create the group then I'd have to do it from within a package since multiple other packages are affected (jack*). --[ background ]-- Historically, the audio group for real-time multimedia has served two purposes: 1. Permissions for real-time scheduling (i.e. PAM) 2. Permissions for device access (e.g. FireWire, RTC, HPET) This new group relates mostly to (1). In the event the 'audio' group proves to be a problem for devices, the new group can be used. This means that a jack user will be in both the 'audio' and 'realtime' groups in this new scheme. --[ background ]-- If nobody objects I'll go ahead and create a new package that creates the new group and configures the relevant permissions. -- GPG/PGP ID: C0711BF1
On Wed, Nov 12, 2014 at 9:14 AM, Rashif Ray Rahman
I am looking to provide support for a 'realtime' group, for use with not just audio/video but any other/future applications of real-time.
The 'audio' group will "remain" for backward compatibility, indefinitely. I can therefore either create the new group or users have to do it.
If I choose to create the group then I'd have to do it from within a package since multiple other packages are affected (jack*).
--[ background ]-- Historically, the audio group for real-time multimedia has served two purposes:
1. Permissions for real-time scheduling (i.e. PAM) 2. Permissions for device access (e.g. FireWire, RTC, HPET)
This new group relates mostly to (1). In the event the 'audio' group proves to be a problem for devices, the new group can be used.
This means that a jack user will be in both the 'audio' and 'realtime' groups in this new scheme. --[ background ]--
If nobody objects I'll go ahead and create a new package that creates the new group and configures the relevant permissions.
The approach of handing out real-time permissions via group or even to individual users isn't secure, as even the minimum RT priority of 1 can be used to DOS the system. We really want something else for future applications. Perhaps we can push systemd into adding a TODO to gain something similar to realtimekit for use by both applications and systemd user services.
On 12 November 2014 14:28, Jan Alexander Steffens
The approach of handing out real-time permissions via group or even to individual users isn't secure, as even the minimum RT priority of 1 can be used to DOS the system. We really want something else for future applications. Perhaps we can push systemd into adding a TODO to gain something similar to realtimekit for use by both applications and systemd user services.
You're absolutely right, especially if we're talking about other applications of real-time. The case with multimedia has been about single-user (sometimes offline) systems mostly, but with the proliferation of capable multimedia networked devices this can and will change. Nevertheless, these users presently would benefit from not being tied to the audio group. I remember there was an issue with systemd+pulseaudio where being in the group meant not being able to give up perms for user switching. I'm not sure how many users will complain if I just let them create this group instead of doing it for them (and reserving an ID, which I did before on a testing update but reverted). -- GPG/PGP ID: C0711BF1
[2014-11-12 14:14:22 +0600] Rashif Ray Rahman:
If nobody objects I'll go ahead and create a new package that creates the new group and configures the relevant permissions.
What would this package provide? If it's only a group, then shouldn't this simply be part of filesystem? In addition, could you give a list of all packages you expect to use this new realtime group (particularly those that do not fit the current audio/video groups)? Cheers. -- Gaetan
On 12 November 2014 14:29, Gaetan Bisson
What would this package provide? If it's only a group, then shouldn't this simply be part of filesystem?
It would provide a group that has security implications, apply pam limits, and some udev perms. I only mentioned a helper package to minimize unwanted intervention, also limiting the security risk to a niche group of users.
In addition, could you give a list of all packages you expect to use this new realtime group (particularly those that do not fit the current audio/video groups)?
The current application for real-time scheduling is only multimedia, so only the following packages are involved: extra/jack community/jack2 The pam security limits are set per package here, and udev rules are added for real-time timer devices. Until systemd/pulseaudio there was no problem with this setup (i.e. the audio group). Other distros usually just let their users go through the necessary hoops. [1] I personally never saw the reason to be that pedantic so I began incorporating those hoops into the jack packages some time ago. TL;DR: I can choose to provide a new group or let users manage this themselves. If I do create a group for them, it must be from within an existing or a new (meta) package. An existing package implies a greater security risk. [1] http://ccrma.stanford.edu/planetccrma/software/installplanettwenty.html (see "Access to realtime scheduling") -- GPG/PGP ID: C0711BF1
participants (3)
-
Gaetan Bisson
-
Jan Alexander Steffens
-
Rashif Ray Rahman