FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 01-25-2012, 09:32 AM
Adrian Knoth
 
Default RFC: Realtime system (audio) group

Hi!

[background story: pro-audio applications run with POSIX realtime
priorities to meet low-latency deadlines. We ship
/etc/security/limits.d/audio.conf in the jackd packages to grant rt
privileges to the audio group]

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.

We can call this group "rtaudio", but maybe somebody prefers a more
generic name, e.g., "realtime". Maybe there is already such a group.


WDYT?


Cheers


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4F1FDA28.9020503@drcomp.erfurt.thur.de">http://lists.debian.org/4F1FDA28.9020503@drcomp.erfurt.thur.de
 
Old 01-25-2012, 10:38 AM
Simon McVittie
 
Default RFC: Realtime system (audio) group

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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4F1FE9AA.6060401@debian.org">http://lists.debian.org/4F1FE9AA.6060401@debian.org
 
Old 01-25-2012, 10:43 AM
Bastian Blank
 
Default RFC: Realtime system (audio) group

On Wed, Jan 25, 2012 at 11:32:08AM +0100, Adrian Knoth wrote:
> [background story: pro-audio applications run with POSIX realtime
> priorities to meet low-latency deadlines. We ship
> /etc/security/limits.d/audio.conf in the jackd packages to grant rt
> privileges to the audio group]

Why does jackd not grant _itself_ RT priority? It can grant itself
CAP_SYS_NICE, which allows arbitrary mangling of priorities.

It could still limit the usage for users with the audio group and just
drop the capability of the user is not in this group.

Bastian

--
No one can guarantee the actions of another.
-- Spock, "Day of the Dove", stardate unknown


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120125114347.GA20506@wavehammer.waldi.eu.org">ht tp://lists.debian.org/20120125114347.GA20506@wavehammer.waldi.eu.org
 
Old 01-25-2012, 10:44 AM
Bastian Blank
 
Default RFC: Realtime system (audio) group

On Wed, Jan 25, 2012 at 11:38:18AM +0000, Simon McVittie wrote:
> rtkit (packaged in Debian) seems a safer way to do this than
> group-based privileges + setuid root.

Why does it use setuid and not CAP_SYS_NICE?

Bastian

--
We Klingons believe as you do -- the sick should die. Only the strong
should live.
-- Kras, "Friday's Child", stardate 3497.2


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120125114442.GB20506@wavehammer.waldi.eu.org">ht tp://lists.debian.org/20120125114442.GB20506@wavehammer.waldi.eu.org
 
Old 01-25-2012, 10:50 AM
Adrian Knoth
 
Default RFC: Realtime system (audio) group

On 01/25/2012 12:44 PM, Bastian Blank wrote:


On Wed, Jan 25, 2012 at 11:38:18AM +0000, Simon McVittie wrote:

rtkit (packaged in Debian) seems a safer way to do this than
group-based privileges + setuid root.


Why does it use setuid


It doesn't use setuid root. Simon has wrongly assumed this.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4F1FEC99.4060103@drcomp.erfurt.thur.de">http://lists.debian.org/4F1FEC99.4060103@drcomp.erfurt.thur.de
 
Old 01-25-2012, 11:17 AM
Adrian Knoth
 
Default RFC: Realtime system (audio) group

On 01/25/2012 12:43 PM, Bastian Blank wrote:


[background story: pro-audio applications run with POSIX realtime
priorities to meet low-latency deadlines. We ship
/etc/security/limits.d/audio.conf in the jackd packages to grant rt
privileges to the audio group]


Why does jackd not grant _itself_ RT priority? It can grant itself
CAP_SYS_NICE, which allows arbitrary mangling of priorities.


# setcap cap_sys_nice,cap_ipc_lock+eip /usr/bin/jackd

Works, but is hardly an improvement. It's either a stability risk (if
not limited) or:


It could still limit the usage for users with the audio group and just
drop the capability of the user is not in this group.


Which would still require the user to be part of a special group. The
audio group can't be used for this, as it would again combine "access to
sound card" and "have realtime permissions" as described in #656910.

So we're back at how to name this group.


Cheers


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4F1FF2EA.8090105@drcomp.erfurt.thur.de">http://lists.debian.org/4F1FF2EA.8090105@drcomp.erfurt.thur.de
 
Old 01-25-2012, 11:31 AM
Adrian Knoth
 
Default RFC: Realtime system (audio) group

On 01/25/2012 12:38 PM, Simon McVittie 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.


As already pointed out, there is no setuid binary.


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.


RT CPU bandwidth is limited to 95% these days. No need for a watchdog
anymore.


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


Is there something like

"If you're logged in locally, I'll grant you RT prios"?

that does not require the application to use dbus? So to say, "@local"
PAM magic or inherited from gdm/kdm/getty?

Can policykit do this? This would be a good compromise between "make it
work for the local user without messing with groups", but still leaving
enough freedom for the experienced if ssh is required.

Note that this would change the default ulimits if logged in locally.
We'd end up with every local user having RT priorities and more or less
unlimited memory locking. AFAIK, it's what OSX does, but it might
require some discussion if it's desired to have the same in Debian.



Cheers


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4F1FF63A.1000509@drcomp.erfurt.thur.de">http://lists.debian.org/4F1FF63A.1000509@drcomp.erfurt.thur.de
 
Old 01-26-2012, 12:32 PM
Josselin Mouette
 
Default RFC: Realtime system (audio) group

Le mercredi 25 janvier 2012 à 13:31 +0100, Adrian Knoth a écrit :
> > 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
>
> Is there something like
>
> "If you're logged in locally, I'll grant you RT prios"?
>
> that does not require the application to use dbus? So to say, "@local"
> PAM magic or inherited from gdm/kdm/getty?

Currently two things are supported by ConsoleKit/PolicyKit: D-Bus
interfaces, and device permissions (udev sets dynamic ACLs on some
devices when you are on the console). If you need things like Unix
sockets, currently there is no code to support them (but there is no
technical limitation).

--
.'`. Josselin Mouette
: :' :
`. `'
`-


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 1327584742.17752.589.camel@pi0307572">http://lists.debian.org/1327584742.17752.589.camel@pi0307572
 

Thread Tools




All times are GMT. The time now is 01:22 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org