On Tue, 23.06.09 09:14, Jonathan Woithe (jwoithe@email-addr-hidden) 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@email-addr-hidden http://lists.linuxaudio.org/mailman/listinfo/linux-audio-devReceived on Tue Jun 23 04:15:07 2009
This archive was generated by hypermail 2.1.8 : Tue Jun 23 2009 - 04:15:07 EEST