On 25/01/12 10:32, Adrian Knoth wrote:
As outlined in #656910, "being in the audio group" and "having realtime priorities" aren't separated at the moment. To make these two independent, we'd need to use a different (new?) group for realtime priorities.
rtkit (packaged in Debian) seems a safer way to do this than group-based privileges + setuid root. It doesn't just hand out realtime priorities, it also has a watchdog thread with a higher priority than the rt application itself, so it can carry out an emergency de-prioritization on the rt application to get control back to your shell/UI if the system becomes unresponsive.
If you have PolicyKit, rtkit defaults to letting you have rt priorities if and only if you are logged in locally (gdm, kdm, getty etc., but not ssh); as with all PK services, the policy is configurable (so a local admin could give this privilege to the audio or users group, or a new group). I'm not sure what its fallback policy is if you don't have PK.
The Debian packages for pulseaudio used to create a pulse-rt group which granted access to realtime priority for the user's instance of the pulseaudio daemon (basically what you're proposing, but Pulse-specific), but since 0.9.16 it's just recommended rtkit instead.
Having to add users to an ever-increasing number of groups so they can run applications as intended seems like an anti-pattern, if there's a sensible default (e.g. involving "only if logged-in locally") with configuration that can override it; this is why PK exists.
S