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

On Mon, 2004-10-18 at 21:04, Jack O'Quin wrote:
> > > 
> > > There are several ways to gain realtime privileges.  Running as
root
> > > is the simplest, but perhaps the worst solution.  
> > 
> > Just to be clear, with ices, you can drop to a nominated user after
the
> > realtime scheduler is selected. Running as root after that is not
> > required.
> 
> That does not solve the problem at all.  If you run jackd as root, you
> must run *all* JACK clients as root.  They are not all coded that way,
> and some cannot be.  Neither they nor jackd should be entrusted with
> God-like superuser powers.
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.

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
and an alternative user is stated in the xml then ices will change to
that user, and therefore _NOT_ run as root anymore. This has been a
common approach for unix apps.

If you use some other mechanism like capabilities then requiring root
for realtime scheduling may not be needed, but that is platform
specific.

karl.

Karl Heyes <karl@xiph.org> writes:
> On Mon, 2004-10-18 at 18:27, Jack O'Quin wrote:
> > Karl Heyes <karl@xiph.org> writes:
> > 
> > > Are you running with realtime privileges, for this you need to
start as
> > > root if you want that. Even with realtime privileges there may be
odd
> > > cases where the scheduling latency is a bit too high, it all
depends on
> > > the drivers and kernel version but the current state is not that
bad and
> > > getting better.
> > 
> > There are several ways to gain realtime privileges.  Running as root
> > is the simplest, but perhaps the worst solution.  
> 
> Just to be clear, with ices, you can drop to a nominated user after the
> realtime scheduler is selected. Running as root after that is not
> required.
That does not solve the problem at all.  If you run jackd as root, you
must run *all* JACK clients as root.  They are not all coded that way,
and some cannot be.  Neither they nor jackd should be entrusted with
God-like superuser powers.
-- 
  joq

>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