What? Why does mpd want to access /root/.config? What’s MPD? It’s a daemon for playing music. It runs as a service, which I connect to with either ncmp or ncmpcpp.

Here’s the full SETroubleshoot detail:

SELinux is preventing mpd from getattr access on the directory /root/.config.

*****  Plugin catchall (100. confidence) suggests   **************************

If you believe that mpd should be allowed getattr access on the .config directory by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# ausearch -c 'mpd' --raw | audit2allow -M my-mpd
# semodule -X 300 -i my-mpd.pp

Additional Information:
Source Context                system_u:system_r:mpd_t:s0
Target Context                unconfined_u:object_r:config_home_t:s0
Target Objects                /root/.config [ dir ]
Source                        mpd
Source Path                   mpd
Port                          
Host                          watamem.local
Source RPM Packages           
Target RPM Packages           
Policy RPM                    selinux-policy-3.13.1-283.26.fc27.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     watamem.local
Platform                      Linux watamem.local 4.15.4-300.fc27.x86_64
                              #1 SMP Mon Feb 19 23:31:15 UTC 2018 x86_64 x86_64
Alert Count                   2
First Seen                    2018-03-01 19:37:10 AEDT
Last Seen                     2018-03-01 19:40:15 AEDT
Local ID                      95638a12-2d84-4060-9339-8f05c61c619e

Raw Audit Messages
type=AVC msg=audit(1519893615.831:1060): avc:  denied  { getattr } for  pid=23997 comm="mpd" path="/root/.config" dev="dm-0" ino=1703951 scontext=system_u:system_r:mpd_t:s0 tcontext=unconfined_u:object_r:config_home_t:s0 tclass=dir permissive=0


Hash: mpd,mpd_t,config_home_t,dir,getattr

The version of MPD that causes this issue is: 0.20.10 on Fedora 27. I’m pretty sure it was working last week and I didn’t have to do anything. So what’s changed? Well, it seems like this could be a very old problem as reported int bug 1325502. Basically, when mpd is started, it tries to read the MPD configuration file (mpd.conf). According to the man page for mpd.conf, the configuration file should be read in the following order:

mpd.conf(5)                                                                              File Formats Manual                                                                              mpd.conf(5)

NAME
       mpd.conf - Music Player Daemon configuration file

DESCRIPTION
       mpd.conf  is  the  configuration file for mpd(1).  If not specified on the command line, MPD first searches for it at $XDG_CONFIG_HOME/mpd/mpd.conf then at ~/.mpdconf then at ~/.mpd/mpd.conf
       and then in /etc/mpd.conf

When mpd service is started (with # systemctl start mpd), the first location MPD starts to look for its config is in /root/.config/mpd/mpd.conf since the service is started by root user. (Of course, $XDG_CONFIG_HOME for root is $HOME/config or /root/.config.)

This can be verified by running strace:

# strace mpd --no-daemon
...
stat("/root", {st_mode=S_IFDIR|0550, st_size=4096, ...}) = 0
stat("/root/.config", {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0
stat("/root/.config/mpd/mpd.conf", 0x7fff42971030) = -1 ENOENT (No such file or directory)
stat("/root", {st_mode=S_IFDIR|0550, st_size=4096, ...}) = 0
stat("/root/.mpdconf", 0x7fff42971030)  = -1 ENOENT (No such file or directory)
stat("/root", {st_mode=S_IFDIR|0550, st_size=4096, ...}) = 0
stat("/root/.mpd/mpd.conf", 0x7fff42971030) = -1 ENOENT (No such file or directory)
stat("/etc/mpd.conf", {st_mode=S_IFREG|0644, st_size=12748, ...}) = 0
openat(AT_FDCWD, "/etc/mpd.conf", O_RDONLY|O_NOCTTY|O_CLOEXEC) = 5
read(5, "# An example configuration file "..., 4096) = 4096
read(5, "blem, it is highly recommended t"..., 4087) = 4087
read(5, "st\t\t\"localhost\"\n#\tport\t\t\"8000\"\n#"..., 4092) = 4092
read(5, " \"loudness\". This setting is dis"..., 4089) = 473
read(5, "", 4096)                       = 0
...

So how to fix this? I think there are 2 ways. The first one which I haven’t even tried yet is to add User=mpd to the [Service] section in /usr/lib/systemd/system/mpd.service. Something like this:

[Service]
User=mpd
Type=notify
ExecStart=/usr/bin/mpd --no-daemon 

In theory, when mpd is started it should looks for $HOME/config/mpd.conf of mpd user, and there should be SELinux problem with access right. However, there are other issues that prevent this method working without fixing more SELinux issue. One of them is:

SELinux is preventing mpd from map access on the file /usr/bin/mpd.

*****  Plugin catchall (100. confidence) suggests   **************************

If you believe that mpd should be allowed map access on the mpd file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# ausearch -c 'mpd' --raw | audit2allow -M my-mpd
# semodule -X 300 -i my-mpd.pp

Additional Information:
Source Context                system_u:system_r:init_t:s0
Target Context                system_u:object_r:mpd_exec_t:s0
Target Objects                /usr/bin/mpd [ file ]
Source                        mpd
Source Path                   mpd
Port                          

So… here is the 2nd solution which is relatively easy and actually fixes problem: modify the mpd.service by explicitly appending the mpd’s configuration as the following:

...
[Service]
Type=notify
ExecStart=/usr/bin/mpd --no-daemon /etc/mpd.conf
...

Then reload the systemd daemon and start mpd as usual:

[root@watamem ~]# systemctl daemon-reload 
[root@watamem ~]# systemctl start mpd

Alright, I’m gonna get back to listen to my music. 😉