Question about supplementary group behavior

[ieure]

Just spent some time debugging an issue I was having, and I have a question about MPD's behavior.

My initial issue was that MPD couldn't open my audio device, even though it has membership in the audio group. I'm using it with a dedicated USB DAC and direct hardware access, no pulse/pipewire/whatever.

Examining /proc/$PID/status showed that the MPD process had no supplementary groups at all. Digging through the code, I found that MPD's behavior is:

• If the MPD configuration has a group setting (ex: group "mpd"), the process gets that group as its GID, but no supplementary groups.
• If there is no group set, the MPD process gets its supplementary groups set.

Here's a sample configuration:

user "mpd"
group "mpd"
log_file "syslog"
music_directory "/star/library/audio/music/flac"
playlist_directory "/star/library/audio/music/playlists"
state_file "~/.cache/mpd/state"
port "6600"
restore_paused "yes"

database {
    plugin "proxy"
    host "library.lab.atomized.org"
    port "6600"
}

audio_output {
    name "SMSL VMV D1"
    type "alsa"
    enabled "yes"
    tags "yes"
    always_on "no"
    mixer_type "software"
    device "default:CARD=USB20"
}

If I run MPD with this configuration, it gets no supplementary groups:

root@amp /home/ieure/projects/mpd# pidof mpd
root@amp /home/ieure/projects/mpd# /gnu/store/p7r1jqkankjivpv03gc6ni84v9kdhy0n-mpd-0.24.5/bin/mpd --stderr --no-daemon --verbose ./mpd.conf &
[1] 11830
root@amp /home/ieure/projects/mpd# config_file: loading file "./mpd.conf"
2025-11-08T14:05:25 server_socket: bind to '0.0.0.0:6600' failed (continuing anyway, because binding to '[::]:6600' succeeded): Failed to bind socket: Address already in use
2025-11-08T14:05:25 libsamplerate: libsamplerate converter "Fastest Sinc Interpolator"
2025-11-08T14:05:25 vorbis: Xiph.Org libVorbis 1.3.7
2025-11-08T14:05:25 opus: libopus 1.5.2
2025-11-08T14:05:25 sndfile: libsndfile-1.2.0
2025-11-08T14:05:25 curl: version 8.6.0
2025-11-08T14:05:25 curl: with GnuTLS/3.8.3
2025-11-08T14:05:25 event: RTIOThread could not get realtime scheduling, continuing anyway: sched_setscheduler failed: Operation not permitted
2025-11-08T14:05:25 state_file: Loading state file /var/lib/mpd/.cache/mpd/state
2025-11-08T14:05:25 playlist: play 0:"Coroner/Mental Vortex/05-Metamorphosis.flac"
2025-11-08T14:05:25 output: OutputThread could not get realtime scheduling, continuing anyway: sched_setscheduler failed: Operation not permitted
2025-11-08T14:05:25 decoder_thread: probing plugin flac
2025-11-08T14:05:25 decoder: audio_format=44100:16:2, seekable=true
grep -E '^([UG]id|Groups)' /proc/$(pidof mpd)/status
Uid:	985	985	985	985
Gid:	979	979	979	979
Groups:	0 
root@amp /home/ieure/projects/mpd# kill %1
root@amp /home/ieure/projects/mpd# 2025-11-08T14:06:00 state_file: Saving state file /var/lib/mpd/.cache/mpd/state
2025-11-08T14:06:00 player: played "Coroner/Mental Vortex/05-Metamorphosis.flac"

[1]+  Done                    /gnu/store/p7r1jqkankjivpv03gc6ni84v9kdhy0n-mpd-0.24.5/bin/mpd --stderr --no-daemon --verbose ./mpd.conf

If I remove the group option, it gets them:

root@amp /home/ieure/projects/mpd# grep -v group mpd.conf > mpd-nogroup.conf
root@amp /home/ieure/projects/mpd# diff -u mpd.conf mpd-nogroup.conf
--- mpd.conf	2025-11-08 14:03:21.730795223 -0800
+++ mpd-nogroup.conf	2025-11-08 14:06:11.210425517 -0800
@@ -1,5 +1,4 @@
 user "mpd"
-group "mpd"
 log_file "syslog"
 music_directory "/star/library/audio/music/flac"
 playlist_directory "/star/library/audio/music/playlists"
root@amp /home/ieure/projects/mpd# pidof mpd
root@amp /home/ieure/projects/mpd#  /gnu/store/p7r1jqkankjivpv03gc6ni84v9kdhy0n-mpd-0.24.5/bin/mpd --stderr --no-daemon --verbose ./mpd-nogroup.conf &
[1] 11866
root@amp /home/ieure/projects/mpd# config_file: loading file "./mpd-nogroup.conf"
2025-11-08T14:08:49 server_socket: bind to '0.0.0.0:6600' failed (continuing anyway, because binding to '[::]:6600' succeeded): Failed to bind socket: Address already in use
2025-11-08T14:08:49 libsamplerate: libsamplerate converter "Fastest Sinc Interpolator"
2025-11-08T14:08:49 vorbis: Xiph.Org libVorbis 1.3.7
2025-11-08T14:08:49 opus: libopus 1.5.2
2025-11-08T14:08:49 sndfile: libsndfile-1.2.0
2025-11-08T14:08:49 curl: version 8.6.0
2025-11-08T14:08:49 curl: with GnuTLS/3.8.3
2025-11-08T14:08:49 event: RTIOThread could not get realtime scheduling, continuing anyway: sched_setscheduler failed: Operation not permitted
2025-11-08T14:08:49 state_file: Loading state file /var/lib/mpd/.cache/mpd/state
2025-11-08T14:08:49 playlist: play 0:"Coroner/Mental Vortex/05-Metamorphosis.flac"
2025-11-08T14:08:49 output: OutputThread could not get realtime scheduling, continuing anyway: sched_setscheduler failed: Operation not permitted
2025-11-08T14:08:49 decoder_thread: probing plugin flac
2025-11-08T14:08:49 decoder: audio_format=44100:16:2, seekable=true
grep -E '^([UG]id|Groups)' /proc/$(pidof mpd)/status
Uid:	985	985	985	985
Gid:	979	979	979	979
Groups:	979 991 
root@amp /home/ieure/projects/mpd# kill %1
root@amp /home/ieure/projects/mpd# 2025-11-08T14:08:59 state_file: Saving state file /var/lib/mpd/.cache/mpd/state
2025-11-08T14:08:59 player: played "Coroner/Mental Vortex/05-Metamorphosis.flac"

For completeness, here are the relevant UIDs/GIDs on this system:

root@amp /home/ieure/projects/mpd# grep mpd /etc/group
audio:x:991:ieure,mpd
mpd:x:979:
root@amp /home/ieure/projects/mpd# grep mpd /etc/passwd
mpd:x:985:979:Music Player Daemon (MPD) user:/var/lib/mpd:/gnu/store/m4qcfmdbh9rl5j07y10ddgkwz3gs5843-shadow-4.13/sbin/nologin

This seems to be intentional behavior, MPD doesn't call initgroups() unless had_group is FALSE. had_group is TRUE if the group configuration option is present, and FALSE otherwise. The behavior was introduced in d718a8b59d1f48abcff7f5626a237c1998fc83d5.

The behavior appears to be undocumented, and is, at least to me, surprising.

What I'd expect is that if you specify group, that sets the PGID, and the user's supplementary groups are still effective. Should it work like it currently does, or how I'd expect it to?

[MaxKellermann]

Yes, it should work like it currently does.
If you explicitly configure a group, that overrides the group(s) in your user database. Why would you want to do that? Don't do it. But if you do, it will override the groups, and it will only use the one group you specified, and nothing else. This whole feature makes little sense. Why would anybody ever want to do that? Why does this feature exist? No idea. Did I say "don't do it" yet?

Of course, that behavior should be documented. Right now, user and group are both completely undocumented.

(Oh, and by the way, the user configuration is obsolete, too. Why would you ever want to start MPD as superuser, anyway? Start it with the credentials that you expect MPD to run as)