On Mon, Mar 08, 2010 at 04:32:39AM +0800, Ray Rashif wrote: 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 !

On Sun, Mar 7, 2010 at 4:14 PM, alex stone <compose59(a)gmail.com> wrote: The main disadvantage is that JACK uses a shared memory architecture. There is no reasonable way to keep clients running for different users from interfering with each other. A clever attacker could probably even trick the root user into doing unsafe things. This should almost certainly not be an installation default. If someone wants to configure it that way, they should at least be warned. -- joq

While I understand the fun of running jackd as root as a system service... On Monday 08 March 2010 03:06:08 torbenh wrote: There is more at stake here: There are these nice network things in jack, so this makes your "local root exploit" (which is bad enough in its own) a "network root exploit". If your alarm bells aren't ringing here, you probably run your machine without any connection to the outside world (no network, usb, floppy, cdrom/dvd)... What about running jackd as user "nobody" and allowing all in the audio group to connect? Trusting "everybody" can go wrong way to fast to even think about it. Oh, please, please don't ever mention running jackd as root again. Yes, it might "fix" some problems. But finding these "fixes" in the archives leads to many innocent googling starters to the dark side of the audio force. Arnold

On Mon, Mar 08, 2010 at 03:06:08AM +0100, torbenh wrote: 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. Ciao, -- FA O tu, che porte, correndo si ? E guerra e morte !

On 08/03/2010, torbenh <torbenh(a)gmx.de> wrote: It looks like the promiscuous part of the code hasn't changed: http://trac.jackaudio.org/changeset/1028 So it should still work, but for some reason connections aren't getting through, although jackd is setting the correct permissions for /dev/shm/$jacktmpdir..a test case I ran by creating a normal user "audio": [root@localhost ~] # useradd -N -K SYS_UID_MAX=499 -K SYS_GID_MAX=499 -s /bin/bash -g audio -G users,video,network -c audio -d /var/lib/jack audio [root@localhost ~] # mkdir -p /var/lib/jack && chown audio:audio /var/lib/jack [root@localhost ~] # su - audio -c 'umask 0000 && export JACK_PROMISCUOUS_SERVER && jack -P55 -dalsa -dhw:0 -r48000 -p512 -n3' *** server start success *** [root@localhost ~] $ ls -l /dev/shm total 0 drwx------ 3 audio audio 60 Mar 9 12:35 jack-1001 Perms are not correct, so try again with JACK_PROMISCUOUS_SERVER="": [root@localhost ~] # killall jackd && su - audio -c 'umask 0000 && export JACK_PROMISCUOUS_SERVER="" && jack -P55 -dalsa -dhw:0 -r48000 -p512 -n3' *** server start success *** [root@localhost ~] $ ls -l /dev/shm total 0 drwxrwxrwx 3 audio audio 60 Mar 9 12:40 jack [root@localhost ~] $ ls -l /dev/shm/*/* total 0 prw-rw-rw- 1 audio audio 0 Mar 9 12:40 jack-ack-fifo-28335-0 prw-rw-rw- 1 audio audio 0 Mar 9 12:40 jack-ack-fifo-28335-1 srwxrwxrwx 1 audio audio 0 Mar 9 12:40 jack_0 srwxrwxrwx 1 audio audio 0 Mar 9 12:40 jack_ack_0 Perms are now correct, so try starting a client with another user "foo": [foo@localhost ~] $ mplayer -ao jack awesome.wav ... ... [JACK] cannot open server Failed to initialize audio driver 'jack' Could not open/initialize audio device -> no sound. Audio: no sound Video: no video Exiting... (End of file) And from http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=500249: "Cause there's no system-wide jackd anymore, it can't be promiscuous." -- GPG/PGP ID: B42DDCAD