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
