|Summary:||Reported SELinux state/status is incorrect|
|Product:||[Fedora] Fedora||Reporter:||Tomas Toth <ttomasz>|
|Component:||smolt||Assignee:||Mike McGrath <mmcgrath>|
|Status:||CLOSED WONTFIX||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||7||CC:||bugzilla, cpanceac, davej, dwalsh, jeff, sds, triage|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2008-06-17 02:14:23 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Tomas Toth 2007-08-26 15:41:53 UTC
Description of problem: # smoltSendProfile -p | grep -i selin SELinux Enabled: False SELinux Enforce: Disabled Incorectly reports "False" & "Disabled", while 'linux' commands repors: "Enabled" & "Enforcing" # /usr/sbin/selinuxenabled # echo $? 0 # /usr/sbin/getenforce Enforcing Version-Release number of selected component (if applicable): smolt.noarch 0.9.8.4-4.fc7 Always reproducible: smoltSendProfile -p Actual results: SELinux Enabled: False SELinux Enforce: Disabled Expected results: SELinux Enabled: 1/Yes/True/Enabled (?) SELinux Enforce: Enforcing Additional info: # smoltSendProfile -p UUID: f60a49e5-bedc-4b11-9897-8395274173df OS: Fedora release 7 (Moonshine) Default run level: 5 Language: en_US.UTF-8 Platform: x86_64 BogoMIPS: 1608.46 CPU Vendor: AuthenticAMD CPU Model: AMD Turion(tm) 64 X2 Mobile Technology TL-52 Number of CPUs: 2 CPU Speed: 1600 System Memory: 1004 System Swap: 1983 Vendor: ASUSTeK Computer INC. System: A7T 1.0 Form factor: laptop Kernel: 220.127.116.11-65.fc7 SELinux Enabled: False SELinux Enforce: Disabled . . .
Comment 1 Stephen Smalley 2007-09-28 15:26:12 UTC
/usr/sbin/selinuxenabled follows the convention of /bin/true (0) and /bin/false (1) for use in shell if statements, so that might be why smolt is getting confused. But I'm not sure why smolt doesn't just use the libselinux python bindings and directly call selinux.is_selinux_enabled(), which does return 1 for enabled and 0 for disabled as one might expect. /usr/sbin/selinuxenabled just calls that and returns its negation. Likewise for getenforce, i.e. selinux.security_getenforce().
Comment 2 Daniel Walsh 2007-09-28 15:36:19 UTC
*** Bug 311181 has been marked as a duplicate of this bug. ***
Comment 3 Daniel Walsh 2007-09-28 15:38:10 UTC
selinux.get_enforcemode() Will also tell you the system default, as opposed to what the machine is currently. selinux.selinux_getpolicytype() Will you tell you the policy type installed
Comment 4 cornel panceac 2007-09-30 08:46:33 UTC
just for reference (x86): " since f8t2, i've noticed that smoltSendProfile is sending this information: SELinux Enabled: False SELinux Enforce: Disabled ( http://rafb.net/p/K52dW671.html ) even if # sestatus SELinux status: enabled SELinuxfs mount: /selinux Current mode: enforcing Mode from config file: enforcing Policy version: 21 Policy from config file: targeted also, i've noticed that on my profile page i can not see this details: http://smolt.fedoraproject.org/show?UUID=4a8aa03c-2af9-4dfb-9146-963580786ed7 it would be nice to have an 'details' link on that page to see all the sent info. " (from fedora-test-list)
Comment 5 Dave Jones 2007-10-01 04:50:38 UTC
*** Bug 299501 has been marked as a duplicate of this bug. ***
Comment 6 Stephen Smalley 2007-10-01 13:52:50 UTC
Looks like the latest devel version now does: selinux.is_selinux_enabled() (-1 == could not tell, 0 == disabled, 1 == enabled) selinux.selinux_getpolicytype() (string name of policy, e.g. 'targeted') But that doesn't tell you permissive vs. enforcing. selinux.security_getenforce() will return the current permissive vs. enforcing status from the kernel (-1 == could not tell, 0 == permissive, 1 == enforcing). selinux.selinux_getenforcemode() will return the setting from /etc/selinux/config (-1 == disabled, 0 == permissive, 1 == enforcing). The latter gives you both enabled vs. disabled and enforcing vs. permissive as a single tristate value, as permissive and enforcing imply enabled.
Comment 7 Heiko Adams 2007-11-02 20:44:40 UTC
Same problem here with EPEL's smolt packages. smolt-0.9.8.4-4.el5 smolt-server-0.9.8.4-4.el5 smolt-gui-0.9.8.4-4.el5 smolt-firstboot-0.9.8.4-4.el5
Comment 8 Bug Zapper 2008-05-14 14:06:40 UTC
This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '7'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 7's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 7 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists. Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs: http://docs.fedoraproject.org/release-notes/ The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 9 Bug Zapper 2008-06-17 02:14:21 UTC
Fedora 7 changed to end-of-life (EOL) status on June 13, 2008. Fedora 7 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.