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 +0000, 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
