Bug 725553

Summary:	luci will not start due to SELinux in default (enforcing) mode [F15]
Product:	[Fedora] Fedora	Reporter:	Jan Pokorný [poki] <jpokorny>
Component:	luci	Assignee:	Jan Pokorný [poki] <jpokorny>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	15	CC:	cfeist, fdinitto, rmccabe
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	luci-0.25.0-1.fc15	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:	725549	Environment:
Last Closed:	2011-09-22 19:09:34 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:
Embargoed:
Bug Depends On:	725549
Bug Blocks:

Description Jan Pokorný [poki] 2011-07-25 20:22:06 UTC

+++ This bug was initially created as a clone of Bug #725549 +++

Description of problem:
See summary + details (grep'd /var/log/audit/audit.log):

type=AVC msg=audit(1311625021.310:360): avc:  denied  { write } for  pid=9075 comm="paster" name="etc" dev=dm-1 ino=17377 scontext=system_u:system_r:piranha_web_t:s0 tcontext=system_u:object_r:piranha_web_conf_t:s0 tclass=dir
type=SYSCALL msg=audit(1311625021.310:360): arch=c000003e syscall=2 success=no exit=-13 a0=20ab390 a1=241 a2=1b6 a3=9 items=0 ppid=9052 pid=9075 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="paster" exe="/usr/bin/python" subj=system_u:system_r:piranha_web_t:s0 key=(null)

Version-Release number of selected component (if applicable):
luci-0.24.0-2.fc15.x86_64

Steps to Reproduce:
0. (luci not installed, tested with fresh installation)
1. # yum install luci
2. # service luci start
  
Actual results:
Starting luci (via systemctl):  Job failed. See system logs and 'systemctl status' for details.
                                                           [FAILED]
# systemctl status luci.service
luci.service - LSB: Starts and stops luci
	  Loaded: loaded (/etc/rc.d/init.d/luci)
	  Active: failed since Mon, 25 Jul 2011 22:17:01 +0200; 3min 40s ago
	 Process: 9052 ExecStart=/etc/rc.d/init.d/luci start (code=exited, status=2/INVALIDARGUMENT)
	  CGroup: name=systemd:/system/luci.service
		  ├ 2393 /usr/sbin/saslauthd -m /var/run/saslauthd -a pam
		  ├ 2395 /usr/sbin/saslauthd -m /var/run/saslauthd -a pam
		  ├ 2396 /usr/sbin/saslauthd -m /var/run/saslauthd -a pam
		  ├ 2397 /usr/sbin/saslauthd -m /var/run/saslauthd -a pam
		  └ 2398 /usr/sbin/saslauthd -m /var/run/saslauthd -a pam



Expected results:
Luci will start, regardless SELinux mode.

Comment 1 Jan Pokorný [poki] 2011-07-25 20:45:58 UTC

This should be fixed in http://git.fedorahosted.org/git/?p=luci.git;a=commit;h=a94f0fb84c12532edc373c3b878b3ef8ebea62c3

The fix came along with solving bug #632536.

Note: Python binary path is hard-coded, but this should be sufficient by now.

Comment 2 Jan Pokorný [poki] 2011-07-26 17:16:22 UTC

It should be explicitly mentioned that stated commit completes the changes made in http://git.fedorahosted.org/git/?p=luci.git;a=commit;h=73f6bf3334e3c95ee4599ebebc4e4404aa04b780 (or "s/fixed in/fixed as of/" in previous comment)

Comment 3 Jan Pokorný [poki] 2011-07-26 17:52:11 UTC

Additional info (if "SELinux vs. luci" case ever needs further investigation):

# rpm -q selinux-policy
selinux-policy-3.9.16-34.fc15.noarch

# sestatus
SELinux status:                 enabled
SELinuxfs mount:                /selinux
Current mode:                   enforcing
Mode from config file:          enforcing
Policy version:                 24
Policy from config file:        targeted

And—under the line—another note which becomes interesting when
compared to the situation with Fedora 14
(https://bugzilla.redhat.com/show_bug.cgi?id=725549#c3):
> in order to start luci successfully, *the only* "/usr/bin/paster" occurrence
> required to be preceded by "/usr/bin/python" in the initscript, whether with
> -Es switch or not (see bug #632536) and despite the fact that paster's
> shebang means (as far as I can say) the same, is the one in "prepare-config"
> function (the one using "make-config" command)