Re: aucat(1) mixing streams from different users
On Tue, Jun 28, 2011 at 05:16:23PM +0200, Landry Breuil wrote: If you're _that_ concerned about mpd privacy, it supports passwd authentication on the tcp socket allowing various levels of control on the daemon.. cf mpd.conf(5). I'm not concerned by mpd privacy, I don't use mpd. But we often get questions like why doesn't mpd work with aucat. The reason is that -- despite what the upstream mpd.conf example suggests -- our port installs a mpd.conf for a system-wide server over TCP running as user _mpd, which was OK in 2006. This is still OK nowadays as long as the user doesn't try to run multiple audio apps simultaneously. -- Alexandre
Re: aucat(1) mixing streams from different users
On Mon, Jun 27, 2011 at 02:21:25PM +, Jona Joachim wrote: The simpler -- and most natural imho -- would be configure mpd to use unix domain sockets (instead of TCP) and to run it as your user id instead of _mpd. If you can't, you can cheat by copying mpd's ~/.aucat_cookie in your home directory (it must have mode 0600) this way aucat will consider _mpd and you are the same person. After all, I guess you run _mpd for you ;) I see, this is the new authentication mechanism kicking in :) Thanks for the explanation, now that I know what's causing it, it's easy to fix. Too bad if this works, because nobody will fix mpd to use unix domain sockets by default ;-) -- Alexandre
Re: aucat(1) mixing streams from different users
On Tue, Jun 28, 2011 at 11:01:26AM +0200, Alexandre Ratchov wrote: On Mon, Jun 27, 2011 at 02:21:25PM +, Jona Joachim wrote: The simpler -- and most natural imho -- would be configure mpd to use unix domain sockets (instead of TCP) and to run it as your user id instead of _mpd. If you can't, you can cheat by copying mpd's ~/.aucat_cookie in your home directory (it must have mode 0600) this way aucat will consider _mpd and you are the same person. After all, I guess you run _mpd for you ;) I see, this is the new authentication mechanism kicking in :) Thanks for the explanation, now that I know what's causing it, it's easy to fix. Too bad if this works, because nobody will fix mpd to use unix domain sockets by default ;-) Well, just running mpd as my user id fixes the problem, no need for unix domain sockets. I usually try to run daemons that don't need to be reached from outside on unix domain sockets, however with mpd the problem is that not all clients support them. Best regards, Jona -- Worse is better Richard P. Gabriel
Re: aucat(1) mixing streams from different users
On Tue, Jun 28, 2011 at 02:45:03PM +0200, Jona Joachim wrote: On Tue, Jun 28, 2011 at 11:01:26AM +0200, Alexandre Ratchov wrote: On Mon, Jun 27, 2011 at 02:21:25PM +, Jona Joachim wrote: The simpler -- and most natural imho -- would be configure mpd to use unix domain sockets (instead of TCP) and to run it as your user id instead of _mpd. If you can't, you can cheat by copying mpd's ~/.aucat_cookie in your home directory (it must have mode 0600) this way aucat will consider _mpd and you are the same person. After all, I guess you run _mpd for you ;) I see, this is the new authentication mechanism kicking in :) Thanks for the explanation, now that I know what's causing it, it's easy to fix. Too bad if this works, because nobody will fix mpd to use unix domain sockets by default ;-) Well, just running mpd as my user id fixes the problem, no need for unix domain sockets. I usually try to run daemons that don't need to be reached from outside on unix domain sockets, however with mpd the problem is that not all clients support them. unfortunately this means that other local users would be able to interact with your instance of mpd, which would be a regression. -- Alexandre
Re: aucat(1) mixing streams from different users
On Tue, Jun 28, 2011 at 3:14 PM, Alexandre Ratchov a...@caoua.org wrote: On Tue, Jun 28, 2011 at 02:45:03PM +0200, Jona Joachim wrote: On Tue, Jun 28, 2011 at 11:01:26AM +0200, Alexandre Ratchov wrote: On Mon, Jun 27, 2011 at 02:21:25PM +, Jona Joachim wrote: The simpler -- and most natural imho -- would be configure mpd to use unix domain sockets (instead of TCP) and to run it as your user id instead of _mpd. If you can't, you can cheat by copying mpd's ~/.aucat_cookie in your home directory (it must have mode 0600) this way aucat will consider _mpd and you are the same person. After all, I guess you run _mpd for you ;) I see, this is the new authentication mechanism kicking in :) Thanks for the explanation, now that I know what's causing it, it's easy to fix. Too bad if this works, because nobody will fix mpd to use unix domain sockets by default ;-) Well, just running mpd as my user id fixes the problem, no need for unix domain sockets. I usually try to run daemons that don't need to be reached from outside on unix domain sockets, however with mpd the problem is that not all clients support them. unfortunately this means that other local users would be able to interact with your instance of mpd, which would be a regression. If you're _that_ concerned about mpd privacy, it supports passwd authentication on the tcp socket allowing various levels of control on the daemon.. cf mpd.conf(5). Landry
aucat(1) mixing streams from different users
Hi, I start mpd and aucat with default settings using rc scripts. aucat thus runs as user _sndio and mpd runs as _mpd. Access to sndio between mpd and programs running as a different user are mutually exclusive, so when mpd is playing music nothing else can access the sound device. According to the aucat(1) manpage: [...] the server can be started by the super-user, [...] but for privacy reasons only one user may have connections to it at a given time. I was wondering if this is intended behaviour because aucat here does not run as root but as _sndio. Best regards, Jona -- Worse is better Richard P. Gabriel
Re: aucat(1) mixing streams from different users
On Mon, Jun 27, 2011 at 02:42:42PM +0200, Jona Joachim wrote: Hi, I start mpd and aucat with default settings using rc scripts. aucat thus runs as user _sndio and mpd runs as _mpd. Access to sndio between mpd and programs running as a different user are mutually exclusive, so when mpd is playing music nothing else can access the sound device. According to the aucat(1) manpage: [...] the server can be started by the super-user, [...] but for privacy reasons only one user may have connections to it at a given time. I was wondering if this is intended behaviour because aucat here does not run as root but as _sndio. This is ok, the _sndio user is to avoid running the server with root privileges, it's not involved in the authentication process. You can find slightly more details about how it works in the AUTHENTICATION section of the sndio(7) man page. The simpler -- and most natural imho -- would be configure mpd to use unix domain sockets (instead of TCP) and to run it as your user id instead of _mpd. If you can't, you can cheat by copying mpd's ~/.aucat_cookie in your home directory (it must have mode 0600) this way aucat will consider _mpd and you are the same person. After all, I guess you run _mpd for you ;) -- Alexandre
Re: aucat(1) mixing streams from different users
On 2011-06-27, Alexandre Ratchov a...@caoua.org wrote: On Mon, Jun 27, 2011 at 02:42:42PM +0200, Jona Joachim wrote: Hi, I start mpd and aucat with default settings using rc scripts. aucat thus runs as user _sndio and mpd runs as _mpd. Access to sndio between mpd and programs running as a different user are mutually exclusive, so when mpd is playing music nothing else can access the sound device. According to the aucat(1) manpage: [...] the server can be started by the super-user, [...] but for privacy reasons only one user may have connections to it at a given time. I was wondering if this is intended behaviour because aucat here does not run as root but as _sndio. This is ok, the _sndio user is to avoid running the server with root privileges, it's not involved in the authentication process. You can find slightly more details about how it works in the AUTHENTICATION section of the sndio(7) man page. The simpler -- and most natural imho -- would be configure mpd to use unix domain sockets (instead of TCP) and to run it as your user id instead of _mpd. If you can't, you can cheat by copying mpd's ~/.aucat_cookie in your home directory (it must have mode 0600) this way aucat will consider _mpd and you are the same person. After all, I guess you run _mpd for you ;) I see, this is the new authentication mechanism kicking in :) Thanks for the explanation, now that I know what's causing it, it's easy to fix. Best regards, Jona -- Worse is better Richard P. Gabriel
