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

[Karl Heyes]

On Mon, 2004-10-18 at 22:14, Paul Davis wrote:
> 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.

Whenever communication is done to an as-root app then the risk *is*
increased (I treat that as fact). The point I was making with ices is
that realtime scheduling is the only aspect that requires root (in
general).  For jackd I can see mlock being a possible problem if you
dropped root privs, mlockall should be ok, but I haven't done much with
that.

> >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.

There are still timing/latency considerations with ices and not just for
things relating to JACK.

> >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.

I was really referring to the general process of starting as root and
then dropping privileges after doing something requiring root (eg
binding port < 1024) as something that is commonly done by unix apps.
The likes of SCHED_FIFO and mlock* are relatively new, and naturally
fell into the as-root-only bucket

ices itself does not use mlockall, in theory it could use mlock, but in
practise mlock hasn't been needed, as long as scheduling occurs.  There
are various internal limits set which can trigger easily if things are
not running well, and this may be something that has been seen by the
original poster. For those people who are really concerned about the
*risk* then realtime scheduling can be disabled in the xml. So far I
have no reports with this.

> 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; }

In general I would think you're going to have this sort of risk with any
potential busy loop when realtime type priority scheduling is involved,
however it is implemented. 

karl.