22 Aug
2003
22 Aug
'03
4:36 p.m.
If I had to venture a guess it was probably more that
some 'intentionally
bad' application could be written to take advantage of a machine that had a
kernel patched for capabilities, and not specifically that jackstart itself
was a problem. I would suspect that a number of developers would not be
particularly concerned with this, but I'll make the observation that I
quickly counted more than 40 Jack applications on the web site this morning.
What percentage of those have actually been tested using a capabilities
based kernel, and what assurance does a user like me have that one of them
doesn't do an rm / intentionally or by mistake?
I think the only risk (that I know off) would be an application that
hangs the machine because there is an infinite loop or lockup in the
audio thread (which is the one that runs with SCHED_FIFO - realtime
schedulling). The capabilities granted by jackstart to jackd (thus to
the jack clients) do not allow the process access to arbitrary files.
Obviously that can happen if you are just running applications as root
and not using capabilities at all (all bets are off if you run as root).
Jack has a watchdog timer that supposedly would kill apps that do that.
It does not always work. When I was having problems with deadlocks in
2.4.20 (traced by Andrew Morton to a bug in the ext3 code) the internal
Jack watchdog process did not kill jack or the offending process. I used
another program (rt_monitor) to do that, and it was pretty effective in
reviving the machine after each lockup.
As this list grows to 100 or
200 apps, how will I - as a user, not a developer - be protected against
something like this?
Not that many choices (against badly behaving jack clients). Watchdog
timers that look for errant processes would be the first. But the _real_
protection should come from a better scheduler that takes that into
account in the kernel itself (I saw messages in a list, can't remember
which, and a patch for such a scheduler).
-- Fernando