Re: sndioctl not working with mpd playing music

On Mon, Apr 27, 2020 at 01:48:27PM +0200, Landry Breuil wrote:
> On Mon, Apr 27, 2020 at 07:38:25AM +0200, Alexandre Ratchov wrote:
> > On Sun, Apr 26, 2020 at 08:40:08PM +0100, Stuart Henderson wrote:
> > >
> > > But....
> > >
> > > The problem with this is, on a multiuser system where you want to share
> > > audio between mpd (or audio/squeezelite, which has the same problem) and
> > > more than one user, you have to share a cookie between _mpd, user1 and
> > > user2, so sndiod's privacy mechanism is nullified.
> > >
> >
> > If mpd was allowed to bypass checks and play while either user1 or
> > user2 are using the device, the privacy mechanism would be affected
> > anyway. For instance user1 would be allowed to start music during
> > phone-calls of user2.
> >
> > > As an alternative, perhaps the mechanism sndiod now uses for root could be
> > > extended for users specified on sndiod's command line. Stupid hardcoded
> > > example for mpd, clearly not committable as-is, but demonstrating the concept.
> > >
> >
> > I'll try implement something like this, it's the safer.
> >
> > It would be nice if _mpd could start as root, open the device, drop
> > privileges then. I just tried it, but this fails because mpd calls
> > setuid() too early, probably not designed for this.
> >
> > The hack below makes mpd open the default device before main() is
> > called, then it reuses the same handle all the time. It works for me,
> > but if the device fails, mpd needs to be restarted; I don't know if
> > this is a problem, I don't use mpd very often.
>
> I like the idea (and this is probably how most openbsd daemons which do
> privdrop work) but this really should be brought up w/ upstream :)
> (which is friendly)
>
> as its an always-running daemon, having the device failing should be
> loud and clear so that the admin/user knows he has to restart, instead
> of silently dying or failing.. what could cause the device failing,
> sndiod dying ? plugging/unplugging a device ?

I was referring to plugging/unplugging USB devices. If the USB device
is unplugged, sndiod disconnects programs using it, so _mpd will will
need to be restarted every time USB cables are swapped even if it's
not playing. During suspend/resume cycles USB devices are detached, so
this is not suitable for laptops using uaudio.

Note that all other players have the same problem since the beginning.

> Fwiw ive been using the var/spool/mpd hack with the aucat cookie
> sharing for many years, and yeah at some point it complained about perms
> but moving to 750 worked for me. Just had to copy the cookie once, so i
> dont think its a big deal to document it in mpd doc.
>
> drwxr-x--- 4 _mpd _mpd 512 Apr 11 09:24 /var/spool/mpd
> -rw------- 1 _mpd _mpd 16 Jan 16 2017 /var/spool/mpd/.aucat_cookie
> -rw------- 1 _mpd _mpd 16 Oct 12 2018 /var/spool/mpd/.sndio/cookie
>
> Im not sure we should address the 'many *real* users want to access
> sndiod' case. And adding a quirk to 'whitelist' a given user within
> sndiod feels a bit like a hidden knob...

I agree.