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
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4f1fe9aa.6060...@debian.org