[Jackit-devel] Re: [Icecast] ices-kh dropping jack ports unexpectedly

[Paul Davis]

>I can't really comment on jackd itself, as I haven't looked that much
>into it.  If running jackd as root requires client apps to also run as
>root then that is a pretty bad issue. I would of thought that running
>jackd as a realtime process (whether root or not) would be an important
>consideration.

jackd (realtime) requires various resources which it shares with its
clients:

      realtime scheduling
      mlock-ability
      shared memory segments
      FIFOs (or Mach ports on OS X)

we consider it *more* of a security risk to allow jackd-as-root to
share these with non-root processes. YMMV.

>What I can say is that ices tries to acquire realtime scheduling if
>enabled (default is yes) which may or may not fail, but if root is used

what ices does is mostly irrelevant to JACK. the thread that handles
audio processing is created by JACK, and that thread does not inherit
any scheduling parameters from its parent. whether other ices thread
run SCHED_FIFO is besides the point, and probably should be discouraged.

>that user, and therefore _NOT_ run as root anymore. This has been a
>common approach for unix apps.

yes, but running with SCHED_FIFO and calling mlockall has not been a
common approach for unix apps. and because unix systems have made it
difficult to grant applications permissions to use these capabilities
with root permission somehow getting involved, adding these to a
client-server design poses some very difficult questions.

ultimately, running anything SCHED_FIFO+mlockall+shm+fifo's opens up a
world of possible DOS attacks on a machine, whether its run as root or
not. my attitude is that until unix gives us better ways to manage
this (and the LSM system in 2.6 is a reasonable start), its really not
sensible to try to apply the conventional unix wisdom to this
situation. or maybe it is ... remember while (1) { fork (); } as the
guaranteed crash-inducer of many unix systems? SCHED_FIFO just
replaces crash with "apparent lockup" caused by while (1) { continue; }

--p