I am experiencing the same issue. I noticed when a auto-relabel happened out of the blue. The only way I have found to disable it is selinux=0 on the kernel command line.

Here is another Ask Fedora thread:
https://ask.fedoraproject.org/question/35512/

Also someone on G+ frustrated about this. Since RH is supposed to be on vacation ATM so we can't rely on Dan fixing it quickly as he usually would, I'll see if I can find what went wrong and if it's something sufficiently simple for the QA monkey to fix...

So this is a bit tricky to work out without dwalsh, because of how libselinux package works. libselinux-rhat.patch does lots of different things without explaining itself either in-line or via git commit messages.

So I went for a conservative approach. I checked upstream, and near as I can tell, nothing has changed here upstream for years, since 2008 really - I don't believe Dan's change to the patch was simply meant to adapt it to some upstream change, I think he was actually trying to change the behaviour of the patch.

I drew up a little test plan for selinux enablement and ran it against the F20 release libselinux (2.1.13-19), the "broken" one (2.2.1-4), and a new build I did (2.2.1-6) which drops the offending stanza from libselinux-rhat.patch.

As I expected, the result of this is that 2.2.1-4 behaves as described in this bug - disabling selinux via the config file never works - and 2.2.1-6 behaves identically to 2.1.13-19.

All three builds have some other issues, but the only case I could find where 2.2.1-4 is better than the other two builds is when you do this:

config file: SELINUX=disabled
cmdline: selinux=1 enforcing=0

I'd probably expect that to result in 'permissive', but with 2.1.13-19 and 2.2.1-6, it results in 'disabled'. With 2.2.1-4 it results in 'permissive'.

Still, that's a rather obscure case, and it seems like fixing that is not worth breaking all disablement via the config file. So I am going to send 2.2.1-6, with this change to rhat.patch reverted, to Rawhide and to F20 as a candidate update. Dan, when you're back, I can provide you with my full set of test results and explain the other cases which behaved other than expected, if you like. One obvious one is https://bugzilla.redhat.com/show_bug.cgi?id=907841 , which is broken for all three libselinux builds (i.e. 2.2.1-4 did not fix that bug, if it was intended to).

btw, as a side note, the implementation of this whole area seems to leave a little to be desired. 

First, we have two ways of configuring SELinux enablement, which use a different approach. The config file considers it a single trinary setting: is "selinux" enforcing, permissive, or disabled? On the cmdline, it's instead implemented as two binary settings: is "selinux" on or off, and is "enforcing" on or off? Obviously, the expected behaviour in all possible cases here is rather less clear than if they both did it the same way.

In the code, we have three different variables zinging around in various files and functions - secmdline, seconfig, and *enforce. selinux_config.c's selinux_getenforcemode function is relatively clear - it sets *enforce to -1 for 'disabled', 0 for 'permissive', and 1 for 'enforcing', i.e. it's clearly backing the config file's trinary state. Fine. But that only covers the config file. load_policy.c does most of the actual heavy lifting here, and so far as I can tell, never clearly explains exactly what it's doing, or what the expected values for any of those three variables are. It's pretty hard for at least this idiot monkey to follow. I *think* the underlying bug here is that various bits of load_policy.c are confused about whether *enforce should be 0 or -1 if selinux is entirely disabled, but it's really difficult to be confident about this, for me anyway. I can't help feeling the code would be a lot simpler and less prone to borkage if both the cmdline and config file methods for configuring selinux's enablement state worked the same way.

libselinux-2.2.1-6.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/libselinux-2.2.1-6.fc20

*** Bug 1046450 has been marked as a duplicate of this bug. ***

libselinux-2.2.1-6.fc20 fixes it for me :)

Package libselinux-2.2.1-6.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing libselinux-2.2.1-6.fc20'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-24058/libselinux-2.2.1-6.fc20
then log in and leave karma (feedback).

libselinux-2.2.1-6.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.

Of course you could consider this a good time to try SELinux again.  And no the bug was not intentional.

Is this bug fixed? My environment is the following:

# rpm -q libselinux
libselinux-2.2.1-6.fc20.i686

# cat /etc/sysconfig/selinux 

# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#     enforcing - SELinux security policy is enforced.
#     permissive - SELinux prints warnings instead of enforcing.
#     disabled - No SELinux policy is loaded.
SELINUX=disabled
# SELINUXTYPE= can take one of these three values:
#     targeted - Targeted processes are protected,
#     minimum - Modification of targeted policy. Only selected processes are protected. 
#     mls - Multi Level Security protection.
SELINUXTYPE=targeted 

# sestatus 
SELinux status:                 enabled
SELinuxfs mount:                /sys/fs/selinux
SELinux root directory:         /etc/selinux
Loaded policy name:             targeted
Current mode:                   enforcing
Mode from config file:          enforcing
Policy MLS status:              enabled
Policy deny_unknown status:     allowed
Max kernel policy version:      28

# cat /proc/cmdline 
BOOT_IMAGE=/boot/vmlinuz-3.13.6-200.fc20.i686 root=UUID=e062105d-5d55-42dc-b1d1-f223771ba0a4 ro rd.md=0 rd.dm=0 rd.luks=0 rhgb quiet

Yes, it should be. 

What does: 

ls -l /etc/sysconfig/selinux 
and
cat /etc/selinux/config

give?

(In reply to Kevin Fenzi from comment #12)
> 
> ls -l /etc/sysconfig/selinux 
-rw-r--r--. 1 root root 548 24 mar 17.26 /etc/sysconfig/selinux

> cat /etc/selinux/config
# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#     enforcing - SELinux security policy is enforced.
#     permissive - SELinux prints warnings instead of enforcing.
#     disabled - No SELinux policy is loaded.
SELINUX=enforcing
# SELINUXTYPE= can take one of these three values:
#     targeted - Targeted processes are protected,
#     minimum - Modification of targeted policy. Only selected processes are protected. 
#     mls - Multi Level Security protection.
SELINUXTYPE=targeted

I'm figuring that I've modified the wrong file (I've used the sed -i command to do this).

But why there are two files?

hint,

$ ls -l /etc/sysconfig/selinux 
lrwxrwxrwx. 1 root root 17 Sep  4  2013 /etc/sysconfig/selinux -> ../selinux/config

sed and symlink are not good friends:

$ echo hello > original.txt
$ ln -s original.txt symlinked.txt
$ ls -l
-rw-rw-r--   1 massi massi     6 28 mar 14.44 original.txt
lrwxrwxrwx   1 massi massi    12 28 mar 14.45 symlinked.txt -> original.txt
$ sed -i 's/hello/world/g' symlinked.txt 
$ ls -l
-rw-rw-r--   1 massi massi     6 28 mar 14.44 original.txt
-rw-rw-r--   1 massi massi     6 28 mar 14.46 symlinked.txt
$ cat original.txt                                                                                                                                                                 
hello
$ cat symlinked.txt                                                                                                                                                                
world

you need to add the --follow-symlinks options to make it work (maybe)

thanks

This is still badly broken.

I have disabled selinux and rebooted.

$ rpm -q libselinux
libselinux-2.2.1-6.fc20.x86_64

$ sestatus
SELinux status:                 disabled

$ cat /etc/sysconfig/selinux 

# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#     enforcing - SELinux security policy is enforced.
#     permissive - SELinux prints warnings instead of enforcing.
#     disabled - No SELinux policy is loaded.
SELINUX=disabled
# SELINUXTYPE= can take one of these two values:
#     targeted - Targeted processes are protected,
#     minimum - Modification of targeted policy. Only selected processes are protected. 
#     mls - Multi Level Security protection.
SELINUXTYPE=targeted 

Yet when I try to install a piece of software to ~/bin I get

install: error: [Errno 13] Permission denied: '/etc/selinux/targeted/contexts/files/file_contexts.homedirs.bin'

In order to fix this problem on my machine I did the following:
cd /etc/selinux/targeted/contexts/files/
sudo chmod 0744 *

This is because several file relating to the home directory were only readable by root thus giving the permission denied.

It's a home directory for Gods sake so why can't I install software to it?

And why is the file being looked at at all when selinux is supposedly disabled?

Fedora 20 if it helps.

This looks like it might be a bug in the coreutils package not respecting the is_selinux_enabled flag.

Although I don't know why those files would not be world readable.

I'm still seeing the bug. I have libselinux 2.2.1-6 installed. When I launch Altera's Quartus I get,

mkdir: /usr/local/tools/Quartus/linux64/liblzma.so.5: no version information available (required by /usr/lib64/libselinux.so.1)
cp: /usr/local/tools/Quartus/linux64/liblzma.so.5: no version information available (required by /usr/lib64/libselinux.so.1)

SELinux status:                 disabled

So the problem here is the files in /etc/selinux/contexts/files/file_context have wrong permissions, such that users can not read them?