DietPi-Software | MPD: Requires root permissions in some cases

[maartenlangeveld]

Creating a bug report/issue

Required Information

• DietPi version |
  G_DIETPI_VERSION_CORE=6
  G_DIETPI_VERSION_SUB=20
  G_DIETPI_VERSION_RC=5
  G_GITBRANCH=master
  G_GITOWNER=Fourdee

• Distro version | 9.6

• Kernel version | Linux DietPi 4.14.79+ Letsencrypt supports Free Noip.com Dynamic DNS #1159 Sun Nov 4 17:28:08 GMT 2018 armv6l GNU/Linux

• SBC device | RPi Zero W (armv6l)

• Power supply used | 5V 2A

• SDcard used | SanDisk ultra

Additional Information (if applicable)

• Software title | MPD
• Was the software title installed freshly or updated/migrated?
  --> updated/migrated by DietPi update to v6.20.5
• Can this issue be replicated on a fresh installation of DietPi? | No idea
• dietpi-bugreport ID | sed -n 5p /DietPi/dietpi/.hw_model

Steps to reproduce

1. Install DietPi v6.19.7
2. Install MPD
3. Check if MPD works --> it works
4. DietPi-update (to v6.20.5)
5. MPD does not work any more

Expected behaviour

• MPD should work as before.

Actual behaviour

• MPD does not output to soundcard anymore

Extra details

cat /var/log/mpd/mpd.log :
Jan 29 02:45 : avahi: Service 'JustBoom DietPi' successfully established.
Jan 29 02:45 : player: played "http://icecast.omroep.nl/radio1-bb-mp3"
Jan 29 02:45 : exception: Failed to open "JustBoom DietPi" [alsa]
Jan 29 02:45 : exception: nested: Failed to open ALSA device "default": Permission denied

!! When changing user from "mpd" back to "root" (as in v6.19.7) in /etc/mpd.conf problem is solved.

[MichaIng]

@maartenlangeveld
Thanks for your report.

We updated MPD to a new version and it runs as mpd user which went well on our and public testing so far.
I think @Fourdee has way better insight but let me do a start:

• Which sound card do you use and how did you configure it (e.g. dietpi-justboom)?
• Just to sort it out, can you try to run mpd as root again:

G_CONFIG_INJECT 'user[[:blank:]]' 'user "root"' /etc/mpd.conf
systemctl restart mpd

EDIT: Ah lol just saw your edit that this indeed was the solution. 😄
Okay I am not deep enough in this matter but we then have to find out why/in which cases root permissions are required or if we can resolve permissions issues another way. Should be possible since the default Debian package and official install instructions run mpd as non-root user as well. If this would cause expected issues, I guess it won't be the default.

[maartenlangeveld]

I have rpi zero w with Justboom Digi Zero HAT
aplay -l
card 0: sndrpijustboomd [snd_rpi_justboom_digi], device 0: JustBoom Digi HiFi wm8804-spdif-0 []
Subdevices: 0/1
Subdevice #0: subdevice #0

[jparnzen]

I can second this issue. I'm running v6.21.1 on an Odroid C2 with a HIFI Shield 2 DAC shield.

If I run mpd with user "mpd" (with or without group "dietpi" set in mpd.conf) then mpd.log shows:

exception: Failed to read mixer for 'HIFI-SHIELD (Alsa)': failed to attach to default: Permission denied

I see this when trying to play a track or even query the server with mpc.

I've checked the groups on the mpd user and it has: mpd audio dietpi. (I may have added one of them in my trying to get stuff working, so not sure if these are all default or not offhand) Does mpd require any additional groups to get things working? Or could it be ACLs? I haven't checked those yet.

Let me know if I can provide any further info or do any testing.

Sidenote: in regard to #2472 mpd v0.21+ now has the ability to include files. Could that be of assistance with preventing per-instance customization overwrites if we updated the version from 0.20.x to 0.21.x?

[Fourdee]

Strange. Only works if we specify group "audio" in mpd.conf. Seems to ignore the audio group when dietpi group selected.

Would appear MPD ignores system applied groups, only applies whats set in mpd.conf.

root@DietPi:~# cat /etc/group | grep audio
audio:x:29:dietpi,mpd

Cant see a way of adding multiple groups to mpd.conf. One of the other.

[MichaIng]

Ah hmm obviously the given group is not added but overrides the groups the user is inside. Perhaps either giving no group works, if user is already added to both via usermod -a -G dietpi audio

Perhaps the same is the case when adding/setting a group via systemd unit, so we need to avoid setting a group there if multiple are required?

[MichaIng]

Just tested. In case of systemd units the Group= is added to the groups instead of overriding it, so everything is fine there.

According to http://www.mpdconf.org/wiki/index.php?title=Mpd.conf setting no group in mpd.conf will then use the users main group, thus "mpd" which is worse...
Man pages do not even list the option, but interesting the part that "you should not set this option when initiating as unprivileged user": https://linux.die.net/man/5/mpd.conf

So another approach would be to not set any user+group in mpd.conf and instead set this inside the systemd unit which does not override the users groups.

[jparnzen]

Thanks for looking into this, @Fourdee and @MichaIng!

@MichaIng : I applied your idea of using Group=audio here in the systemd mpd unit, as well as set the User=mpd in the unit. I also commented the user and group entries in mpd.conf. Things look good here on the C2 + HIFI Shield 2 with those changes!

The only possible gotcha may be the ExecStartPre= entries, especially with the chown line--that one seemed to burp in journald.

Any reason why mpd should use the dietpi group at all and not just use the audio group? Does the dietpi group bring anything special to this service?

[MichaIng]

@jparnzen

I applied your idea of using Group=audio here in the systemd mpd unit

Group=audio should not even be required, since the mpd user already is inside this group.

The only possible gotcha may be the ExecStartPre= entries, especially with the chown line--that one seemed to burp in journald.

ExecStartPre= commands should then be prefixed with !: https://www.freedesktop.org/software/systemd/man/systemd.service.html#ExecStart=

AFAIK there was another setting to allow ExecStartPre= with root permissions, but can't find it currently.

---

But indeed it is quite different if the initial mpd binary is executed as non-privileged user or it forks of a sub process as non-privileged user. That it works in your case is already a good test, so generally ownership/permissions of the files/dirs accessed by the binary seem to allow this. But should be tested at best by some more users, e.g. during beta phase for v6.22 😃.

[Fourdee]

@MichaIng

PermissionsStartOnly=true

Will apply the fix and patch for v6.22

[Fourdee]

Test with RPi:

• 🈯️

Resolved for v6.22.