Bug 880761

Setting SElinux to permissive or disabled appears to remove the delay on my system

There's a few people reporting this in a forum thread:

http://forums.fedoraforum.org/showthread.php?t=286100

The initial reporter, mdfed, attached various logs but not audit.log to this post:

http://forums.fedoraforum.org/showpost.php?p=1615711&postcount=3

he was advised to turn off selinux and reported "setting selinux to permissive solved my problem. no more gdm errors in the logfiles."

nonamedotc said "I have also been seeing this for a while. Thanks yellowman!", implying he also resolved the issue by setting selinux to permissive.

yellowman, who advised the others to set selinux permissive, posted an extract from his audit.log at http://forums.fedoraforum.org/showpost.php?p=1615977&postcount=9 .

screamin_jesus is the reporter of this bug.

So we have four people who see slow GDM loading resolved by setting selinux to permissive in 18. Dan, Miroslav, Ray, can you look at this? Thanks! Proposing as Final blocker in case this turns out to be a widespread issue, it arguably hits "Following on from the previous criterion, after firstboot is completed and on subsequent boots, a system installed according to any of the above criteria (or the appropriate Beta or Final criteria, when applying this criterion to those releases) must boot to a working graphical environment without unintended user intervention. This includes correctly accessing any encrypted partitions when the correct passphrase is supplied" (Alpha) in the context of a Final release.

(In reply to comment #2)

> nonamedotc said "I have also been seeing this for a while. Thanks
> yellowman!", implying he also resolved the issue by setting selinux to
> permissive.
> 
> yellowman, who advised the others to set selinux permissive, posted an
> extract from his audit.log at
> http://forums.fedoraforum.org/showpost.php?p=1615977&postcount=9 .

Hi Adam, sorry I couldn't generate the log report  before

https://bugzilla.redhat.com/show_bug.cgi?id=880953


Leigh (aka yellowman)

Could you execute after login in permissive mode

# ausearch -m user_avc


I am just installing a new F18 virtual machine to see where the problem is.

leigh: oh that's you? I never catch nick changes!

(In reply to comment #4)
> Could you execute after login in permissive mode
> 
> # ausearch -m user_avc
> 
> 
> I am just installing a new F18 virtual machine to see where the problem is.

I've only seen the issue on bare metal and haven't managed to reproduce in vbox.

I haven't seen this myself in any of my F18 testing (lots of VM testing, some metal testing on my desktop). So it's clearly hardware/config dependent in _some_ way. But equally, it's affecting several people.

(In reply to comment #7)
> I haven't seen this myself in any of my F18 testing (lots of VM testing,
> some metal testing on my desktop). So it's clearly hardware/config dependent
> in _some_ way. But equally, it's affecting several people.

I'm using a nvidia GT450 with 304.64 driver and gigabyte mobo with 1055t proc

You are right. I don't see it in on my virtual machine.

Leigh,
if you add a local policy module

# grep execmem /var/log/audit/audit.log |audit2allow -M mypol
# semodule -i mypol.pp

Does it fix the issue?

Created attachment 653460 [details]
New denied message

(In reply to comment #10)
> Leigh,
> if you add a local policy module
> 
> # grep execmem /var/log/audit/audit.log |audit2allow -M mypol
> # semodule -i mypol.pp
> 
> Does it fix the issue?

It fixes the first error but has exposed this.

Ok, so you see the same behaviour with the local policy in enforcing mode and you get this user_avc?

(In reply to comment #12)
> Ok, so you see the same behaviour with the local policy in enforcing mode
> and you get this user_avc?

Yes I get a similar 20-30 second delay.

ok, just curious about

# grep init_t /var/log/audit/audit.log |audit2allow -M mynewpol
# semodule -i mynewpol.pp

(In reply to comment #14)
> ok, just curious about
> 
> # grep init_t /var/log/audit/audit.log |audit2allow -M mynewpol
> # semodule -i mynewpol.pp

Running the above command fixes the delay.

Great. Thank you for your testing.

Fixed in selinux-policy-3.11.1-57.fc18

selinux-policy-3.11.1-57.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/selinux-policy-3.11.1-57.fc18

(In reply to comment #16)
> Great. Thank you for your testing.

Thank you for fixing the second issue, the plymouth one is still present.

https://bugzilla.redhat.com/show_bug.cgi?id=880953

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

It sounds like this has been fixed, could someone affected by this bug test the fix from c#20 and comment on the results of testing?

(In reply to comment #21)
> It sounds like this has been fixed, could someone affected by this bug test
> the fix from c#20 and comment on the results of testing?

It fixes the original issue here.

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

It sounds like the issue has been fixed with the update from c#23 based on the report in c#22 and no new reports for a while.

Moving to VERIFIED

selinux-policy-3.11.1-60.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.