23 Jun
2009
23 Jun
'09
6:44 a.m.
Lennart Poettering wrote:
On Mon, 22.06.09 23:46, Jörn Nettingsmeier
(nettings(a)folkwang-hochschule.de) wrote:
That is simply bogus.
With the reset-on-fork kernel patch in place you can perfectly
supervise an RT process and it cannot evade you. If the system becomes
unresponsive (which is all that we try to detect), then we can
demote/kill everyone who's misbehaving.
you don't need to fork in order to do wreak havoc.
how do you make sure you know which processes (i.e. which executables)
deserve rt rights? hash them?
and whatever you do, the moment the user loads a user-defined plugin
from a user-controlled location (such as a privately installed LADSPA
plugin), you are utterly hosed.
or am i missing something fundamental here? in which case please
enlighten me.
btw, i'm not quite sure what RTLIMIT_RTTIME is supposed to do. you
define a maximum amount of time that can be spent in rt mode, per user?
or per process? or per group?
if per user, how is scheduling fairness accomplished? does the first rt
process grab as much as it wants, and then another rt process gets
demoted by rtkit because the user used up their rt slice?
What is
so difficult to understand that rtkit is not intended to be a
solution for hardcore rt users?
rtkit is not for you!
Let me repeat this:
RTKIT IS NOT FOR YOU!
this is getting childish. my claim is: if you give rt to a
user, you
enable him to fuck the machine up. that's a law of nature. you can do
all kinds of very clever things and try to have a very fast watchdog,
but it doesn't prevent abuse.