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> |
Severity: | high | Docs Contact: | |
Priority: | medium | ||
Version: | 23 | CC: | dominick.grift, dwalsh, j.orti.alcaine, lvrabec, mgrepl, opensource, plautrba |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: | |||
Fixed In Version: | selinux-policy-3.13.1-155.fc23 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2015-11-26 20:58:17 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Bug Depends On: | 1278268 | ||
Bug Blocks: |
Description
Adam Williamson
2015-11-05 06:42:11 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. 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 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... It's probably caused by the integration of the selinux policy in the main package, but I'm not sure why. 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. (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? Yes, I integrated the radicale-selinux package into the main radicale package. Ok there needs to be an upgrade issue. I don't see how it could reset a default value of a boolean. Why is there a boolean? I see no reason for this boolean, it would be better to fix this problem though labeling. We added fixes to the policy spec file to keep local boolean modifications after upgrade. selinux-policy-3.13.1-155.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2015-0d84d6c75f 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 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. |