[LAD] [ANNOUNCE] Safe real-time on the desktop by default; Desktop/audio RT developers, read this!

[Lennart Poettering]

On Tue, 23.06.09 09:14, Jonathan Woithe (jwoithe at 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