Description of problem: I just tried to start couchdb ( systemctl start couchdb ) SELinux is preventing /usr/lib64/erlang/erts-5.10.1/bin/beam.smp from 'search' accesses on the directory /var/lib/couchdb. ***** Plugin catchall (100. confidence) suggests *************************** If vous pensez que beam.smp devrait être autorisé à accéder search sur couchdb directory par défaut. Then vous devriez rapporter ceci en tant qu'anomalie. Vous pouvez générer un module de stratégie local pour autoriser cet accès. Do autoriser cet accès pour le moment en exécutant : # grep beam.smp /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context system_u:system_r:rabbitmq_beam_t:s0 Target Context system_u:object_r:couchdb_var_lib_t:s0 Target Objects /var/lib/couchdb [ dir ] Source beam.smp Source Path /usr/lib64/erlang/erts-5.10.1/bin/beam.smp Port <Inconnu> Host (removed) Source RPM Packages erlang-erts-R16B-0.3.fc19.x86_64 Target RPM Packages couchdb-1.2.2-2.fc19.x86_64 Policy RPM selinux-policy-3.12.1-47.fc19.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux (removed) 3.9.4-300.fc19.x86_64 #1 SMP Fri May 24 22:17:06 UTC 2013 x86_64 x86_64 Alert Count 5 First Seen 2013-06-02 10:13:19 CEST Last Seen 2013-06-02 10:13:22 CEST Local ID a696bd4a-d3d7-4ff3-8e26-1a2edf8ae96a Raw Audit Messages type=AVC msg=audit(1370160802.273:913): avc: denied { search } for pid=17385 comm="beam.smp" name="couchdb" dev="dm-2" ino=1524045 scontext=system_u:system_r:rabbitmq_beam_t:s0 tcontext=system_u:object_r:couchdb_var_lib_t:s0 tclass=dir type=SYSCALL msg=audit(1370160802.273:913): arch=x86_64 syscall=open success=no exit=EACCES a0=7f427ca81288 a1=0 a2=1b6 a3=0 items=0 ppid=1 pid=17385 auid=4294967295 uid=480 gid=464 euid=480 suid=480 fsuid=480 egid=464 sgid=464 fsgid=464 ses=4294967295 tty=(none) comm=beam.smp exe=/usr/lib64/erlang/erts-5.10.1/bin/beam.smp subj=system_u:system_r:rabbitmq_beam_t:s0 key=(null) Hash: beam.smp,rabbitmq_beam_t,couchdb_var_lib_t,dir,search Additional info: reporter: libreport-2.1.4 hashmarkername: setroubleshoot kernel: 3.9.4-300.fc19.x86_64 type: libreport
It also likely need to read : - system_u:object_r:couchdb_var_run_t:s0 - system_u:object_r:couchdb_conf_t:s0 ( /etc/couchdb and like something in /run ). In fact, i am not sure the label for /usr/lib64/erlang/erts-5.10.1/bin/beam.smp is correct in the first place :/ $ rpm -qf /usr/lib64/erlang/erts-5.10.1/bin/beam.smp erlang-erts-R16B-0.3.fc19.x86_64 $ ls -lZ /usr/lib64/erlang/erts-5.10.1/bin/beam.smp -rwxr-xr-x. root root system_u:object_r:rabbitmq_beam_exec_t:s0 /usr/lib64/erlang/erts-5.10.1/bin/beam.smp
Couchdb also start df as part of the init, and this lead to mesage like : type=SYSCALL msg=audit(1370161244.840:1047): arch=x86_64 syscall=statfs success=yes exit=0 a0=18751e0 a1=7fff9cf6da50 a2=7fff9cf6ddf0 a3=0 items=0 ppid=18493 pid=18494 auid=4294967295 uid=480 gid=464 euid=480 suid=480 fsuid=480 egid=464 sgid=464 fsgid=464 ses=4294967295 tty=(none) comm=df exe=/usr/bin/df subj=system_u:system_r:rabbitmq_beam_t:s0 key=(null) ( trying to look at /home/ /sys/fs/cgroup/systemd and others ).
Yes, I am thinking I would to change the labeling and re-wrote the policy. I added fixes for now.
selinux-policy-3.12.1-48.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/selinux-policy-3.12.1-48.fc19
Package selinux-policy-3.12.1-48.fc19: * should fix your issue, * was pushed to the Fedora 19 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-48.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-10204/selinux-policy-3.12.1-48.fc19 then log in and leave karma (feedback).
It doesn't seems to be fixed, I have : # rpm -q selinux-policy selinux-policy-3.12.1-48.fc19.noarch and couchdb still doesn't start ( still the same AVCs )
selinux-policy-3.12.1-48.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.
I see #============= rabbitmq_beam_t ============== #!!!! This avc is allowed in the current policy allow rabbitmq_beam_t couchdb_var_lib_t:dir search; Try to use the latest builds http://koji.fedoraproject.org/koji/buildinfo?buildID=425949
Hi, I am running: selinux-policy-3.12.1-59.fc19.noarch couchdb-1.2.2-3.fc19.x86_64 and I am also not able to start my CouchDB. I filtered these lines from /var/log/messages: setroubleshoot: SELinux is preventing /usr/lib64/erlang/erts-5.10.1/bin/beam.smp from write access on the directory /var/lib/couchdb/.delete. For complete SELinux messages. run sealert -l ed2d5d47-50fb-420d-ae5c-f1ad2e47abcb setroubleshoot: SELinux is preventing /usr/lib64/erlang/erts-5.10.1/bin/beam.smp from read access on the directory /var/lib/couchdb/.delete. For complete SELinux messages. run sealert -l 7e8dc5d1-d0e9-4291-a584-ed7631412017 setroubleshoot: SELinux is preventing /usr/lib64/erlang/erts-5.10.1/bin/beam.smp from search access on the directory couchdb. For complete SELinux messages. run sealert -l 4835befb-2eab-4a0e-bfa8-f34bb09bdfb8 setroubleshoot: SELinux is preventing /usr/lib64/erlang/erts-5.10.1/bin/beam.smp from search access on the directory /var/log/couchdb. For complete SELinux messages. run sealert -l 2801ca41-7bbe-477c-bb5d-5969171b932b I think that selinux is still blocking access to /var/log/couchdb? kind regards, Egon
Added additional fixes.
Oops, sorry for that. I didn't mean to close it.
selinux-policy-3.12.1-65.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/selinux-policy-3.12.1-65.fc19
Created attachment 774846 [details] CouchDB selinux problem: /var/log/messages
I am sorry. I am still unable to start CouchDB with selinux in enforcing mode. It only starts with selinux in permissive mode. I attached my /var/log/messages as an attachment to this bug. kind regards, Egon
Package selinux-policy-3.12.1-65.fc19: * should fix your issue, * was pushed to the Fedora 19 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-65.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-13172/selinux-policy-3.12.1-65.fc19 then log in and leave karma (feedback).
Sorry, I had to give negative karma. I am running the specified selinx-policy version, but CouchDB does not start. I hope the attachment in comment #13 contains enough information to fix this.
According to https://fedoraproject.org/wiki/QA:Update_feedback_guidelines , if a update fix multiple bug, you should not give negative karma as it prevent the update to be pushed to others who would benefit from it. I will reboot my laptop to test that issue and see if I can provides a patch, or diagnose any issues.
Created attachment 775498 [details] output of sealert -l 109eefa2-d0ee-439b-a00f-c1622f464acb
I am sorry I messed up with the karma on the Bodhi system. Not my intention. I thought it would be smart to compensate my negative karma, but that did not work out the way I expected either...
Created attachment 775503 [details] patch to add a few missing allow rules
Here is a patch that should fix some issues ( not tested ).
selinux-policy-3.12.1-65.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.
Reopen, per previous comments
Egon, could you attach AVC msgs rather than /var/log/messages. Thank you.
Created attachment 776934 [details] Lines containing 'denied' in /var/log/audit/audit.log No problem. I attached the related 'denied' messages from /var/log/audit/audit.log
What I did to produce these lines in /var/log/audit/audit.log: 1) set selinux to enforcing 2) systemctl restart couchdb.service kind regards, Egon
As of selinux-policy-3.12.1-193.fc20, if you relabel your entire filesystem the only remaining couchdb selinux problems are solved by the patches in #1163533.