[LAD] jack daemon scripts

[torbenh]

On Mon, Mar 08, 2010 at 01:14:52AM +0300, alex stone wrote:
> On Mon, Mar 8, 2010 at 12:25 AM,  <fons at kokkinizita.net> wrote:
> > On Mon, Mar 08, 2010 at 04:32:39AM +0800, Ray Rashif wrote:
> >
> >> After further testing, it appears JACK_PROMISCUOUS_SERVER no longer
> >> works. Paul, is that intentional?
> >
> > Indeed it doesn't. There's at least one error in
> > /etc/conf.d/jack-audio-connection-kit: the '-d'
> > in the driver options leads to a double '-d' in
> > the final command line. But that isn't the reason
> > things don't work.
> >
> > It should be noted that Archlinux provides the
> > script in /etc/rc.d but does not in any way use
> > it unless the user takes action (that is normal
> > Arch policy, if you want any daemons you have to
> > add them manually to /etc/rc.conf). So far I was
> > completely unaware of its existence.
> >
> > I'd be *VERY HAPPY* if jackd could be used as
> > a system daemon, with e.g. access limited to
> > members of a the audio group. Or even unlimited.
> > It would simplify things here *A LOT*.
> >
> > Ciao,
> >
> > --
> > FA
> >
> > O tu, che porte, correndo si ?
> > E guerra e morte !
> > _______________________________________________
> > Linux-audio-dev mailing list
> > Linux-audio-dev at lists.linuxaudio.org
> > http://lists.linuxaudio.org/listinfo/linux-audio-dev
> >
> 
> Out of curiosity, what's the pros and cons of using jackd as a system daemon?

first of all its not tested. and it doesnt work.
thats only a problem with permissions though
after some chmod on /dev/shm/jack running jack_lsp as nobody works.
but the patch needs to be either removed or fixed. 

second, and more important reason. jack isnt designed to be secure in
any way. a malicious client can easily make jackd crash. and since its
possible to write data into the servers addressspace, its pretty likely
that its possible to make this crash execute code with jackd privilege
level. 

otoh there are probably enough other local root exploits, so i guess
this doesnt really matter. and a system where normal untrusted users
get handed RT privileges is doomed anyways :)

so basically as long as you trust your users to the point that they dont
want to hack into the system, its probably ok.


-- 
torben Hohn