On Mon, Mar 08, 2010 at 12:22:50PM +0100, fons(a)kokkinizita.net 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