Bug 147615
Summary: | /etc/sysconfig/selinux is ignored | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Joe Cooper <joe> |
Component: | kernel | Assignee: | Dave Jones <davej> |
Status: | CLOSED NOTABUG | QA Contact: | Brian Brock <bbrock> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 3 | CC: | dwalsh, jmorris, pfrields, wtogami |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2005-02-10 14:01:26 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Joe Cooper
2005-02-09 20:46:19 UTC
Just to add to this thread. Adding the following to file_contexts and running restorecon on the /cache0 directory causes the above expected results (I just wanted to confirm that there are no other traditional Unix permissions issues, or anything else weird): # # Squid /cache directories # /cache.*(/.*)? system_u:object_r:squid_cache_t So, permissive is definitely not really permissive. OK, more noise for this issue: After a reboot (with the contexts set as described above, which made it work), squid fails to start. The context is still set: [root@localhost /]# ls -Zd /cache0 drwxr-xr-x squid squid system_u:object_r:squid_cache_t /cache0 But squid -z fails and service squid start fails. The following (slightly different) avc denied error appears in dmesg: audit(1107984720.897:0): avc: denied { getattr } for pid=15694 exe=/usr/sbin/squid path=/cache0 dev=hdc2 ino=2 scontext=root:system_r:squid_t tcontext=system_u:object_r:nfs_t tclass=dir This has me thoroughly confused...I can't figure out where the nfs_t stuff is coming from. I guess getattr is given this context for some reason? I also can't figure out why this behavior doesn't present itself for /var/spool/squid, given that I've set /cache0 to the same context. Clearly I've done something wrong in the policy, but I don't understand what (and it doesn't change the fact that permissive doesn't permit getattr). BTW-I marked this as a regression because I saw a "permissive doesn't work" bug earlier, but this actually seems mostly unrelated to that one, so I've changed it to normal severity. Please provide the output of sestatus when this happens. [root@localhost ~]# sestatus SELinux status: enabled SELinuxfs mount: /selinux Current mode: enforcing Mode from config file: enforcing Policy version: 18 Policy from config file:targeted Policy booleans: allow_ypbind active dhcpd_disable_trans inactive httpd_disable_trans inactive httpd_enable_cgi active httpd_enable_homedirs active httpd_ssi_exec active httpd_tty_comm inactive httpd_unified active mysqld_disable_trans inactive named_disable_trans inactive named_write_master_zonesinactive nscd_disable_trans inactive ntpd_disable_trans inactive portmap_disable_trans inactive postgresql_disable_transinactive snmpd_disable_trans inactive squid_disable_trans inactive syslogd_disable_trans inactive winbind_disable_trans inactive ypbind_disable_trans inactive OK, so I was wrong (and I had no idea sestatus existed, thanks for pointing it out). permissive mode is simply not taking effect. I've checked and double-checked to be sure there is no extraneous white-space in the /etc/sysconfig/selinux file. What am I doing wrong? It may be worth adding that the boot log contains the following (which is what I was basing my belief that my box was booting into permissive mode despite indications to the contrary): Security Framework v1.0.0 initialized SELinux: Initializing. SELinux: Starting in permissive mode OK, fun times. /etc/sysconfig/selinux is ignored completely. /etc/selinux/config has the desired impact, and permissive mode now works as advertised, including allowing all of the stuff I expected to work earlier. So the bug now is that there is an inactive /etc/sysconfig/selinux file, and an undocumented /etc/selinux/config that works. Quite a bit easier to understand this problem, anyway! /etc/sysconfig/selinux was the location in FC2. Upgrading to FC3 should have created a symlink. Anyways /etc/selinux/config is documented in the FAQ in many places. man selinux also documents /etc/selinux/config The /etc/selinux/config configuration file controls whether SELinux is enabled or disabled, and if enabled, whether SELinux operates in per- missive mode or enforcing mode. The Fedora Core 3 FAQ has the old location: http://fedora.redhat.com/docs/selinux-faq-fc3/index.html#id2825945 http://fedora.redhat.com/docs/selinux-faq-fc3/index.html#id2825945 The file /etc/sysconfig/selinux exists on a freshly installed FC3 system...I didn't create the file. That's very confusing, IMHO, since sysconfig is where I go looking for files of this sort. (It isn't owned by any package, so I'm not sure where it's coming from.) Should I refile a documentation issue? |