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.
