On Tue, 23.06.09 09:14, Jonathan Woithe (jwoi...@physics.adelaide.edu.au) wrote:
> > Lennart Poettering wrote: > > What I am saying is that the current system is too "binary": Either > > you have RT sched and then for *everything*. Or you haven't, and then > > you haven't got it for *anything*. > > But isn't this more to do with the missing userspace support infrastructure > that numerous people have pointed to than RTPRIO itself? RTPRIO itself does > not imply this "all or nothing" restriction since it *can* be set on a > per-application basis (given appropriate support in userspace for > doing so). You are misunderstanding what I was saying: either a process is SCHED_RR/FIFO or it is not. That's a binary thing. Either you get the full RT powers, or no RT powers at all. Desktop media stuff doesn't need the full RT powers. > I also had a problem with the way PAM did the "all or nothing" approach and > so I wrote set_rlimits - which grants user-specified RT privileges via > RTPRIO on a user/group/program-specific basis. It's not perfect (one has to > start applications via set_rlimits - eg: "set_rlimits ardour") but it works > for me and didn't take all that long to write. Given this I'm sure others > could come up with a workable RTPRIO-based system which included a nice > user-friendly GUI configuration applet (and so forth) - set_rlimits is a > proof-of-concept in a way which shows that something like this can be done. > > I mention this because from where I stand on the periphery it seems to me > that the major issues with RTPRIO could well have been solved if the > related userspace support infrastructure had been written. Processes with rtprio can fork as much as they want. With ptrace or LD_PRELOAD or a similar mechanism users can load whatever they want into those processes. That's why RLIMIT_RPRIO is not safe, and not even remotely so. > > For the desktop case you need something in between: RT that cannot be > > misused, basically. Doing that securely is particularly hard ... > > Almost anything involving elevated privileges can and will be abused in > time. That's why the action requires elevated privileges in the first > place. Sure, but that's no reason not to at least try to make the system safe for abuses. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 _______________________________________________ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev