|Summary:||httpd_can_read_write_radicale boolean reset from 'on' to 'off' in upgrade from F21 to F23|
|Product:||[Fedora] Fedora||Reporter:||Adam Williamson <awilliam>|
|Component:||selinux-policy||Assignee:||Miroslav Grepl <mgrepl>|
|Status:||CLOSED ERRATA||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||23||CC:||dominick.grift, dwalsh, j.orti.alcaine, lvrabec, mgrepl, opensource, plautrba|
|Fixed In Version:||selinux-policy-3.13.1-155.fc23||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2015-11-26 20:58:17 UTC||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
|Bug Depends On:||1278268|
Description Adam Williamson 2015-11-05 06:42:11 UTC
Comment 1 Adam Williamson 2015-11-05 06:47:09 UTC
I'm thinking the problem is that /var/lib/radicale is owned by radicale.radicale but the script is running as httpd user? not really sure.
Comment 2 Juan Orti 2015-11-05 08:09:36 UTC
It should run with radicale:radicale if you configured it like in the example /etc/httpd/conf.d/radicale.conf: WSGIDaemonProcess radicale user=radicale group=radicale threads=1 umask=0027 Please, make sure you have activated the SELinux boolean httpd_can_read_write_radicale: setsebool -P httpd_can_read_write_radicale 1
Comment 3 Adam Williamson 2015-11-05 17:04:05 UTC
Hmm. I had it right in radicale.conf , but getsebool shows the boolean as off, which is strange, because I'd previously turned it on: [root@www srvad]# history | grep setseb 787 setsebool -P httpd_can_read_write_radicale on And indeed if I set it back to 'on', radicale starts working again. somehow I guess SELinux flipped the boolean back to 'off' when I upgraded from F21 to F23? So re-assigning to something selinux-y...
Comment 4 Juan Orti 2015-11-05 19:45:40 UTC
It's probably caused by the integration of the selinux policy in the main package, but I'm not sure why.
Comment 5 Juan Orti 2015-11-06 06:43:24 UTC
Thinking more about it, the module is removed when the radicale-selinux is obsoleted and then re-installed, so that must be the cause of the booleans resetting to their defaults.
Comment 6 Miroslav Grepl 2015-11-09 08:28:29 UTC
(In reply to Juan Orti from comment #5) > Thinking more about it, the module is removed when the radicale-selinux is > obsoleted and then re-installed, so that must be the cause of the booleans > resetting to their defaults. Ok so there was a radicale-selinux packcage, correct?
Comment 7 Juan Orti 2015-11-09 08:30:33 UTC
Yes, I integrated the radicale-selinux package into the main radicale package.
Comment 8 Miroslav Grepl 2015-11-09 08:43:31 UTC
Ok there needs to be an upgrade issue. I don't see how it could reset a default value of a boolean.
Comment 9 Daniel Walsh 2015-11-13 22:03:20 UTC
Why is there a boolean? I see no reason for this boolean, it would be better to fix this problem though labeling.
Comment 10 Miroslav Grepl 2015-11-20 13:25:08 UTC
We added fixes to the policy spec file to keep local boolean modifications after upgrade.
Comment 11 Fedora Update System 2015-11-20 13:27:09 UTC
selinux-policy-3.13.1-155.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2015-0d84d6c75f
Comment 12 Fedora Update System 2015-11-22 14:26:16 UTC
selinux-policy-3.13.1-155.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with $ su -c 'dnf --enablerepo=updates-testing update selinux-policy' You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-0d84d6c75f
Comment 13 Fedora Update System 2015-11-26 20:57:33 UTC
selinux-policy-3.13.1-155.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.