22 Jun
2009
22 Jun
'09
1:16 p.m.
On Sun, 21.06.09 21:16, Paul Davis (paul(a)linuxaudiosystems.com) wrote:
I wasn't around at those discussions back then, and neither was I in
the position I am in now. My views on that story is that back then RT
for audio was only relevant for audio _production_, and the folks
involved didn't see a problem with asking the user to become a member
of some group.
Nowadays, RT for audio is relevant for the normal desktop use case,
too. And asking for group membership or some other way to bump
RLIMIT_RTPRIO is very bad UI. Almost no user can make a properly
informed decision before agreeing to that.
So, the situation changed since then. What was a bit of a niche
feature in those days is now something that should be exposed by
default. And this asks for reinvestigating the whole story, and making
RT less "binary", as mentioned above, and supervising its use.
Back then desktop folks were not involved. polkit was not around and
it was a bit of a nichey special-purpose feature. All that changed
now.
The kernel patch was discussed publicly on lkml. I discussed this on
IRC with a couple of folks involved, whose OK I was looking for.
Also, the kind of anti-desktop fud war that errupted as a result to
this little announcement on lad is not really a convincing argument for
always keeping all of LAD in the loop.
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
On Sun, Jun 21, 2009 at 7:52 PM, Lennart Poettering<mzynq(a)0pointer.de> wrote:
this is quibbling over details. sched_setschedparam() *should* work -
its documented as working, the kernel and the higher levels of the OS
provide a mechanism to grant priviledge but ... it isn't. so the fix
is to add a new call? is this really what are you saying?
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*.
For the desktop case you need something in between: RT that cannot be
misused, basically. Doing that securely is particularly hard, which is
the reason why we still haven't got it. Only if this solution "in
between" is found, we can enable RT by default for normal users.
Now, a lot of suggestions have been made to fix this over the
years. RLIMIT_RTPRIO, isochronous scheduling, using cgroups and so
on. All of those solutions turned out to be suboptimal and never got
adopted by the distros in a wide scale, or haven't even made into the
kernel.
Now, rtkit is another approach, a lot simpler, and something that was
in the end implementable in just a few days of work, with only minor
changes necessary on the kernel side. Something "good enough", to for
being adopted for the next few years.
Since it enforces all kinds of policy on its clients this little tool
lives in userspace, so that the policy parameters don't have to be
encoded in the kernel.
Now, as mentioned rtkit might not be a solution for eternity. However
it is a solution that should be good enough for quite some time.
Maybe one day we get isochronous scheduling in the kernel with all the
"adding up" issues fixed in a clean way. That day we can kill rtkit
again from the distros. Should be easy enough given how minimal the
interfacing between apps and rtkit actually is.
so, sched_setschedparam(), a documented,
implemented and demonstrably
functional call fails in some cases. and your proposal is to replace
this well-established API with a new API that doesn't actually
accomplish anything new except *WORKING* ?
No. I am not talking about *replacing*. I have asked for adding
support for rtkit to it. > go and ask
linus or ingo and/or whoever is deputized to handle (a)
> scheduling and (b) priviledge control mechanisms. if they come back
Now, if you think you have a better insight into
how things should be
done than all of us, then hey, be my guest, why don't you make some
*proper* suggestions how an alternative should be looking like? Asking
for "creative use" and giving the fault to the distributors just
doesn't cut it.
you seem to have missed the fact that we went through just such a
discussion about 3 years ago when RLIMIT_RTPRIO was first added. there
was wide discussion about how to do this. there was specific
expectation that distros would provide mechanisms for enabling (and
disabling) its use. it was *explicitly* intended to be
group-controllable. now you inform us that "it has been decided" that
this is bad design. ok, we learn from mistakes and we move on. but
everytime this happens, it makes it harder to trust the next choice.
and what happened after the last decision was made about how to
support/configure this ... The big
problem with RLIMIT_RTPRIO is that it is vulnerable to a
combined fork bomb/busy loop attack. Which I btw documented in the
README (which I figure you didn't read?). Because that is the way it
is, we, the distributors, never enabled RLIMIT_RTPRIO by default. What
did happen is that some distros added an ugly unsecure kludge by
adding "jackuser" group or suchlike that you can add a user to that
had RLIMIT_RTPRIO set. But that's hardly a clean solution, and also
leaves the "out-of-the-box" issue unresolved.
except that i could find you posts from people on the l-k mailing list
3 years ago that argued precisely the opposite: that this was
*exactly* the solution that was in keeping with other kernel security
policy/design issues. You seem to
suggest that I wasn't talking to the kernel folks before I
do something like this. That is wrong. This announcement of mine was
just the last step in doing all this, not the first step.
so, who of the half-dozen people from the LAD world who contributed to
the discussion that led to RLIMIT_RTPRIO did you include? there seem
to be some remarkably short-lived memories in kernel land if people
there are so ready to support what is essentially a workaround to what
used to be the Right Answer.