22 Jun
2009
22 Jun
'09
10:06 p.m.
On Tue, 23.06.09 09:14, Jonathan Woithe (jwoithe(a)physics.adelaide.edu.au) wrote:
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
Lennart Poettering wrote:
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.
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). 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.