[pulseaudio-discuss] PA_REALTIME_GROUP not honored if over 1000

[Lennart Poettering]

On Mon, 30.07.07 21:41, Jim Carter (jimc at math.ucla.edu) wrote:

> 
> On Mon, 30 Jul 2007, Lennart Poettering wrote:
> 
> > This was intended to be a protection against misuse of this
> > feature. Maybe it wasn't such a good idea.
> > --snip--
> > I wonder though how much value there still is in the pulse-rt stuff
> > given that we now have the ability to set rt privs via PAM.
> 
> Thanks for your info.  I'm of two minds here: the PAM limit module does 
> seem to be a good solution.  On a shared server, like in an instructional 
> lab with undergraduates who like to hack, one probably wouldn't want to 
> allow any realtime scheduling or renicing, whereas on a personal machine 
> you would be more likely to open this up for everyone.  But would it be 
> sufficient, do you think, to just let the sysop turn on the setUID bit, or 
> not, and maintain the state via /etc/permissions.local?

What is /etc/permissions.local? This file is non-existant on Fedora or
Debian/Ubuntu.

Files in /usr are the realm of the package manager, not of the
administrator. Thus requiring the user to change SUID bits on files
from that tree is not a good idea.

On a "personal" machine you probably don't have more than one, maybe
two users, so this should be relatively easy to add everyone to the
"pulse-rt" group.

I think I will keep both pulse-rt and add proper support for
PAM. Then, you can choose PAM and set the rt limits globally. And
others, who want to allow rt just for very specific users and only for
pa can use pulse-rt.

Lennart

-- 
Lennart Poettering                   Red Hat, Inc.
lennart [at] poettering [dot] net    ICQ# 11060553
http://0pointer.net/lennart/      GnuPG 0x1A015CC4