7 Mar
2010
7 Mar
'10
12:02 p.m.
On 08/03/2010, Ray Rashif <schivmeister(a)gmail.com> wrote:
On 08/03/2010, Paul Davis
<paul(a)linuxaudiosystems.com> wrote:
Oops, clicked on the wrong reply button.
--
GPG/PGP ID: B42DDCAD
On Sun, Mar 7, 2010 at 10:17 AM, Philipp
<hollunder(a)lavabit.com> wrote:
It runs as (1) a dummy user or (2) a normal, real user if configured.
It will fail if there is no user defined. If I recall correctly, you
do not consider running jackd as root an appropriate way to run jack.
But if you say you do not condone automatically starting jackd on
bootup or having a daemon for it, then I'm sure this functionality
will be gladly removed. Hi there.
The distro I'm using installs a script with jack that lets it run as a
daemon.
I know that I personally do not consider this an appropriate way to
run JACK, and I am irritated by distributions that do this. That
doesn't mean I'm right.
7 Mar
7 Mar
3:32 p.m.
New subject: jack daemon scripts
On 08/03/2010, Ray Rashif <schivmeister(a)gmail.com> wrote:
On 08/03/2010, Ray Rashif
<schivmeister(a)gmail.com> wrote:
> On 08/03/2010, Paul Davis <paul(a)linuxaudiosystems.com> wrote:
>> On Sun, Mar 7, 2010 at 10:17 AM, Philipp <hollunder(a)lavabit.com> wrote:
>>> Hi there.
>>> The distro I'm using installs a script with jack that lets it run as a
>>> daemon.
>>
>> I know that I personally do not consider this an appropriate way to
>> run JACK, and I am irritated by distributions that do this. That
>> doesn't mean I'm right.
>
> It runs as (1) a dummy user or (2) a normal, real user if configured.
> It will fail if there is no user defined. If I recall correctly, you
> do not consider running jackd as root an appropriate way to run jack.
>
> But if you say you do not condone automatically starting jackd on
> bootup or having a daemon for it, then I'm sure this functionality
> will be gladly removed.
After further testing, it appears JACK_PROMISCUOUS_SERVER no longer
works. Paul, is that intentional?
Google tells me that at least Debian has since abandoned the method,
but I cannot find any credible source to verify that claim (only one
jackaudio.org article mentioning the variable in an old 0.109 release
notes).
Some peculiarities:
export JACK_PROMISCUOUS_SERVER
umask 0000
/usr/bin/jackd $JACK_PARAMS
Will only allow root to run jackd. Take note that the variable is only
exported, but not set.
export JACK_PROMISCUOUS_SERVER=""
umask 0000
/usr/bin/jackd $JACK_PARAMS
Will only allow root to run jackd, but will _not_ allow any client to
connect, not even root's. Is that because jackd detects the variable
and will refuse any connection? But that doesn't make any sense.
If there aren't any other solution to allow for a multi-user jackd
daemon, then I'll request for the package above to remove the scripts.
I think in that case netjack would be more of a solution for a
multi-user DAW machine (with thin clients).
--
GPG/PGP ID: B42DDCAD
4:29 p.m.
New subject: jack daemon scripts
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 !
5:15 p.m.
New subject: jack daemon scripts
On Mon, Mar 8, 2010 at 12:25 AM, <fons(a)kokkinizita.net> wrote:
On Mon, Mar 08, 2010 at 04:32:39AM +0800, Ray Rashif
wrote:
Out of curiosity, what's the pros and cons of using jackd as a system daemon?
Alex.
--
www.openoctave.org
midi-subscribe(a)openoctave.org
development-subscribe(a)openoctave.org
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(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
8:43 p.m.
New subject: jack daemon scripts
On Sun, Mar 7, 2010 at 4:14 PM, alex stone <compose59(a)gmail.com> wrote:
Out of curiosity, what's the pros and cons of
using jackd as a system daemon?
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
9:05 p.m.
New subject: jack daemon scripts
On Mon, Mar 08, 2010 at 01:14:52AM +0300, alex stone wrote:
On Mon, Mar 8, 2010 at 12:25 AM,
<fons(a)kokkinizita.net> wrote:
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
On Mon, Mar 08, 2010 at 04:32:39AM +0800, Ray
Rashif wrote:
Out of curiosity, what's the pros and cons of using jackd as a system daemon? 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(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
8 Mar
8 Mar
5:44 a.m.
New subject: jack daemon scripts
While I understand the fun of running jackd as root as a system service...
On Monday 08 March 2010 03:06:08 torbenh wrote:
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 :)
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)...
so basically as long as you trust your users to the
point that they dont
want to hack into the system, its probably ok.
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
6:27 a.m.
New subject: jack daemon scripts
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.
Ciao,
--
FA
O tu, che porte, correndo si ?
E guerra e morte !
7:08 a.m.
New subject: jack daemon scripts
On Mon, Mar 08, 2010 at 11:43:53AM +0100, Arnold Krille wrote:
While I understand the fun of running jackd as root as
a system service...
i am actually not talking about jackd running as root.
but any user who has access to it, can shoot it down.
On Monday 08 March 2010 03:06:08 torbenh wrote:
what network things ?
do you mean netjack ?
thats a pretty different piece of cake.
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 :)
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)...
i am not talking about running jackd as root.
(thats not the idea of PROMISCUOUS patch 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.
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. _______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
--
torben Hohn
7:17 a.m.
New subject: jack daemon scripts
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:
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
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.
9 Mar
9 Mar
12:02 a.m.
New subject: jack daemon scripts
On 08/03/2010, torbenh <torbenh(a)gmx.de> wrote:
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.
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
10 Mar
10 Mar
2:14 p.m.
New subject: jack daemon scripts
On Tue, Mar 09, 2010 at 01:02:13PM +0800, Ray Rashif wrote:
On 08/03/2010, torbenh <torbenh(a)gmx.de> wrote:
this looks good, and will work.
you needs to set JACK_PROMISCUOUS_SERVER for all clients also.
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.
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
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
--
torben Hohn
5194
days inactive
5197
days old
linux-audio-dev@lists.linuxaudio.org
11 comments
6 participants
participants (6)
-
alex stone -
Arnold Krille -
fons＠kokkinizita.net -
Jack O'Quin -
Ray Rashif -
torbenh