On Mon, Mar 08, 2010 at 12:22:50PM +0100, [email protected] wrote: > On Mon, Mar 08, 2010 at 03:06:08AM +0100, torbenh wrote: > > > 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. > > This risk always exists once you allow a user to use Jack, > it doesn't matter if that happen under his own login (as > would be permitted with promiscuous) or using a second > 'shared' identity (as is required now if there is more > than one user). The latter is probably even less safe. > > And at least here, a computer being hacked is probably > the least of all risks. Any user getting access to the > system can damage it in much more expensive ways. > > Allowing access based on group membership would be ideal, > at least for my use.
all that is needed is fixing up the permissions of the files jackd creates in /dev/shm/jack its pretty possible that umask( 0002 ); would fix this. then just make sure the user under which jackd is running has his primary group set to audio i am talking about jack1 here. tschack has promiscous mode too. i am not aware of this functionality in jack2. -- torben Hohn _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
