> 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
