Description of problem: Just started mpd. Not sure if this is a bug or not really. SELinux is preventing /usr/bin/mpd from 'search' accesses on the directory /home/asinha/.mpd. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that mpd should be allowed search access on the .mpd 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: # grep mpd /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context system_u:system_r:mpd_t:s0 Target Context unconfined_u:object_r:user_home_t:s0 Target Objects /home/asinha/.mpd [ dir ] Source mpd Source Path /usr/bin/mpd Port <Unknown> Host (removed) Source RPM Packages mpd-0.17.5.89d2d64-1.fc21.x86_64 Target RPM Packages Policy RPM selinux-policy-3.12.1-75.fc20.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux (removed) 3.11.1-300.fc20.x86_64 #1 SMP Sat Sep 14 15:01:23 UTC 2013 x86_64 x86_64 Alert Count 3 First Seen 2013-09-18 16:21:21 EST Last Seen 2013-09-18 16:24:23 EST Local ID 679eded5-e7ed-4037-b06e-385f2fd7d2d8 Raw Audit Messages type=AVC msg=audit(1379485463.653:1250): avc: denied { search } for pid=31778 comm="mpd" name=".mpd" dev="sda2" ino=9962246 scontext=system_u:system_r:mpd_t:s0 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=dir type=SYSCALL msg=audit(1379485463.653:1250): arch=x86_64 syscall=stat success=no exit=EACCES a0=7f4a884fa8a0 a1=7fff166de080 a2=7fff166de080 a3=0 items=0 ppid=1194 pid=31778 auid=4294967295 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 ses=4294967295 tty=(none) comm=mpd exe=/usr/bin/mpd subj=system_u:system_r:mpd_t:s0 key=(null) Hash: mpd,mpd_t,user_home_t,dir,search Additional info: reporter: libreport-2.1.7 hashmarkername: setroubleshoot kernel: 3.11.1-300.fc20.x86_64 type: libreport
Hi, Is this path "/home/asinha/.mpd" default location or you change it?
Not him but: yes this is default. See: http://fpaste.org/40407/79499694/
It's one of the default paths that it searches. From the mpd.conf man page: "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." I'm using the same /home partition from F19 where it worked just fine. Thanks, Warm regards, Ankur
Looks like we need to add "mpd_home_t" type for this location and allow mpd to manage it.
I agree.
done and added to the repo.
Seems there was already i type for mpd user home content: mpd_user_data_t
I created the modules as the troubleshooter advised for the time being. I get subsequent denials for: - open .mpd/mpd.conf - read mpd/mpd.conf - write mpd/mpd.conf - getattr .mpd - read/write .mpd - getattr .mpd - a few to do with pid files and then a bunch with pulseaudio too. I'll file all the bugs when I can. I'm not sure if they're all related etc. It used to work with F19 just fine I think? I really dont' remember running into selinux issues with mpd. Also, this is when I invoke mpd with a systemd --user method. If I run mpd manually from a terminal: 'mpd &', it runs just fine. Thanks, Ankur
selinux-policy-3.12.1-83.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/selinux-policy-3.12.1-83.fc20
Package selinux-policy-3.12.1-83.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing selinux-policy-3.12.1-83.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-17722/selinux-policy-3.12.1-83.fc20 then log in and leave karma (feedback).
I got a scriptlet failure on update: 1 libsemanage.semanage_seuser_set_sename: SELinux user system_u does not exist (No such file or directory). 2 libsemanage.seuser_parse: could not parse seuser record (Invalid argument). 3 libsemanage.dbase_file_cache: could not cache file database (Invalid argument). 4 libsemanage.semanage_base_merge_components: could not merge local modifications into policy (Invalid argument). 5 /usr/sbin/semodule: Failed! This could be caused by the local modules I created following directions from selinux troubleshooter: [root@ankur ~]$ semodule -l | egrep mpd mpd-1009280-mpd-dir 1.0 mpd-1009280-open 1.0 mpd-1009280-pid 1.0 mpd-1009280-pid1 1.0 mpd-1009280-read 1.0 mpd-1009280-write 1.0 mpd-1009280 1.0 mpd 1.0.4 Could you tell me how to remove these and get back to the modules the package ships? semodule doesn't work for me: [root@ankur ~]$ semodule -r mpd-1009280 libsemanage.semanage_seuser_set_sename: SELinux user system_u does not exist (No such file or directory). libsemanage.seuser_parse: could not parse seuser record (Invalid argument). libsemanage.dbase_file_cache: could not cache file database (Invalid argument). libsemanage.semanage_base_merge_components: could not merge local modifications into policy (Invalid argument). semodule: Failed! [root@ankur ~]$ A yum reinstall doesn't work either. How would I get back my pristine module set? Thanks, Ankur
[root@ankur ~]$ semodule -d mpd-1009280 -r mpd-1009280 -v Attempting to disable module 'mpd-1009280': Ok: return value of 0. Attempting to remove module 'mpd-1009280': Ok: return value of 0. Committing changes: libsemanage.semanage_seuser_set_sename: SELinux user system_u does not exist (No such file or directory). libsemanage.seuser_parse: could not parse seuser record (Invalid argument). libsemanage.dbase_file_cache: could not cache file database (Invalid argument). libsemanage.semanage_base_merge_components: could not merge local modifications into policy (Invalid argument). semodule: Failed! [root@ankur ~]$
It has been fixed in the latest libsemanage build.
Ah! I thought I broke something and did a fresh install XD No worries. I'll install the update and give it karma. Thanks, Ankur
Doesn't completely fix it. I get new selinux messages now: SELinux is preventing /usr/bin/mpd from search access on the directory /home/asinha/.config. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that mpd should be allowed search 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: # grep mpd /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context system_u:system_r:mpd_t:s0 Target Context unconfined_u:object_r:config_home_t:s0 Target Objects /home/asinha/.config [ dir ] Source mpd Source Path /usr/bin/mpd Port <Unknown> Host localhost.localdomain Source RPM Packages pulseaudio-4.0-4.gita89ca.fc20.x86_64 Target RPM Packages Policy RPM selinux-policy-3.12.1-83.fc20.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name localhost.localdomain Platform Linux localhost.localdomain 3.11.1-300.fc20.x86_64 #1 SMP Sat Sep 14 15:01:23 UTC 2013 x86_64 x86_64 Alert Count 13 First Seen 2013-09-30 00:20:43 EST Last Seen 2013-09-30 00:25:05 EST Local ID 59fc31c1-1ec5-407c-8898-617208cbc1c0 Raw Audit Messages type=AVC msg=audit(1380464705.895:2161): avc: denied { search } for pid=14036 comm="pulseaudio" name=".config" dev="sda2" ino=9961480 scontext=system_u:system_r:mpd_t:s0 tcontext=unconfined_u:object_r:config_home_t:s0 tclass=dir type=SYSCALL msg=audit(1380464705.895:2161): arch=x86_64 syscall=open success=no exit=EACCES a0=1ad42d0 a1=80000 a2=1b6 a3=3 items=0 ppid=11900 pid=14036 auid=4294967295 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 ses=4294967295 tty=(none) comm=pulseaudio exe=/usr/bin/pulseaudio subj=system_u:system_r:mpd_t:s0 key=(null) Hash: mpd,mpd_t,config_home_t,dir,search I've already restored the contents of all my config files, just to be sure. mpd manages to start up, but it doesn't play songs and instead throws up this AVC denial error. Giving the update a -1 karma for this Thanks, Ankur
The mpd docs don't specify .config any where. It's one of those undocumented things I guess.
Could you run your test in permissive mode and gather all of the AVC messages?
Created attachment 805184 [details] mpd denials with selinux in enforcing mode Hi Daniel, These are what I got. Hope this helps. Thanks, Warm regards, Ankur
Yes thanks. eb52c2b0b095dd2c8c0bc5c11ea1b2158f9e273c fixes this in git.
Package selinux-policy-3.12.1-84.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing selinux-policy-3.12.1-84.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-17722/selinux-policy-3.12.1-84.fc20 then log in and leave karma (feedback).
This message is a reminder that Fedora 20 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 20. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '20'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 20 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.