Bug 964693 - Firefox-21 update broken/unusable
Firefox-21 update broken/unusable
Status: CLOSED EOL
Product: Fedora
Classification: Fedora
Component: firefox (Show other bugs)
20
x86_64 Linux
unspecified Severity urgent
: ---
: ---
Assigned To: Jan Horak
Fedora Extras Quality Assurance
: SELinux
: 981737 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-05-19 10:51 EDT by John Mellor
Modified: 2015-06-29 07:57 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-06-29 07:57:52 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description John Mellor 2013-05-19 10:51:14 EDT
Description of problem:
Firefox-21 locks up

Version-Release number of selected component (if applicable):
firefox-21.0-3.fc18.x86_64

How reproducible:
every time

Steps to Reproduce:
1. yum update
2. firefox-21 installed
3. open firefox, even in safe mode
4. home page come up, but that's the last thing that works.
5. Even stop does not work.  Force close required to exit.
  
Actual results:
Completely useless firefox.

Expected results:
Normally-functioning firefox.

Additional info:
Machine has upgraded firefox many times in the past, without issues.  This uypdate is broken.
This is a fully up-to-date Fedora-18-x64 before update.
Running "yum update" upgrades firefox and xulrunner, along with a couple of other unassociated updates.
Running firefox brings up the home page and the congratulations page on separate tabs as per normal.  However, nothing can be clicked on.  Exit can only be performed by clicking the close button, waiting for the notice of a non-responding app, and forcing close.
Overnight, another minor firefox update was released (update firefox.x86_64 0:21.0-2.fc18 to firefox.x86_64 0:21.0-3.fc18) which does not correct the primary problem.
Running "yum downgrade" is the only workable recovery identified.  Firefox-17 works normally.

Conclusion: Firefox-21 as-built is broken and unusable on Fedora.

Side-note 1: Yum db problem: Running "yum downgrade firefox xulrunner" downgrades to firefox-17 for some reason, even though firefox-20 works well.
Side note 2: Bugzilla db problem: Firefox-20 is not listed in the releases in Bugzilla, even though it is released.
Comment 1 Jan Horak 2013-05-20 03:48:45 EDT
Thanks for you bug report. Please try to run Firefox in safemode, ie.
 firefox -safe-mode
with fresh profile
 firefox -ProfileManager.
and with upstream binaries:
ftp://ftp.mozilla.org/pub/firefox/releases/21.0/linux-x86_64/
Please let us know what is working and what's not from above.
Comment 2 Jan Horak 2013-05-20 03:51:08 EDT
Sorry, I've missed you've already tried safe mode. Please try other suggestions.
Comment 3 John Mellor 2013-05-20 09:00:18 EDT
By creating a new profile, I reset my home page.  The culprit appears to be an inability to render slashdot.org.

Visiting slashdot.org locks up Firefox.
Comment 4 Jan Horak 2013-05-20 09:14:00 EDT
Hm, can you replicate this issue with upstream binaries, ie. from: 
ftp://ftp.mozilla.org/pub/firefox/releases/21.0/linux-x86_64/
Comment 5 Fedora Admin XMLRPC Client 2013-05-20 12:33:01 EDT
The Fedora 20 component was created in error. We only create new Fedora versions when we branch a new release. These bugs are all being moved to rawhide. 

Please retarget them to 19 if they also apply to the Fedora 19 branched release. 

Thanks.
Comment 6 Michael Wiktowy 2013-05-21 14:46:58 EDT
I am seeing this behaviour in Firefox 21 update to Fedora 18.

It is freezing on multiple websites and if you wait long enough before killing it, Firefox will pop-up numerous Script Unresponsive dialogs listing swf and js files both external and internal (components:). One internal error was something along the lines of nsBlocklist ... could not get/remember more since the dialog wouldn't allow cut and paste.
Comment 7 Michael Wiktowy 2013-05-21 15:06:23 EDT
It might be a flash plugin vs. SELinux issue. I am getting a lot of SELinux denials in /var/log/messages even when I start Firefox in safe-mode.

May 21 14:51:45 localhost kernel: [ 6919.749884] type=1400 audit(1369162305.272:41): avc:  denied  { execute } for  pid=6352 comm="plugin-containe" path="/usr/lib64/mozilla/plugins-wrapped/nswrapper_32_64.libflashplayer.so" dev="sda3" ino=1966220 scontext=unconfined_u:unconfined_r:mozilla_plugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:mozilla_plugin_rw_t:s0 tclass=file
May 21 14:51:45 localhost kernel: [ 6919.749947] type=1400 audit(1369162305.272:42): avc:  denied  { execute } for  pid=6352 comm="plugin-containe" path="/usr/lib64/mozilla/plugins-wrapped/nswrapper_32_64.libflashplayer.so" dev="sda3" ino=1966220 scontext=unconfined_u:unconfined_r:mozilla_plugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:mozilla_plugin_rw_t:s0 tclass=file
May 21 14:52:30 localhost kernel: [ 6964.774283] type=1400 audit(1369162350.319:43): avc:  denied  { execute } for  pid=6355 comm="plugin-containe" path="/usr/lib64/mozilla/plugins-wrapped/nswrapper_32_64.libflashplayer.so" dev="sda3" ino=1966220 scontext=unconfined_u:unconfined_r:mozilla_plugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:mozilla_plugin_rw_t:s0 tclass=file
May 21 14:52:30 localhost kernel: [ 6964.774346] type=1400 audit(1369162350.319:44): avc:  denied  { execute } for  pid=6355 comm="plugin-containe" path="/usr/lib64/mozilla/plugins-wrapped/nswrapper_32_64.libflashplayer.so" dev="sda3" ino=1966220 scontext=unconfined_u:unconfined_r:mozilla_plugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:mozilla_plugin_rw_t:s0 tclass=file
May 21 14:53:15 localhost kernel: [ 7009.799789] type=1400 audit(1369162395.366:45): avc:  denied  { execute } for  pid=6364 comm="plugin-containe" path="/usr/lib64/mozilla/plugins-wrapped/nswrapper_32_64.libflashplayer.so" dev="sda3" ino=1966220 scontext=unconfined_u:unconfined_r:mozilla_plugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:mozilla_plugin_rw_t:s0 tclass=file
May 21 14:53:15 localhost kernel: [ 7009.799853] type=1400 audit(1369162395.366:46): avc:  denied  { execute } for  pid=6364 comm="plugin-containe" path="/usr/lib64/mozilla/plugins-wrapped/nswrapper_32_64.libflashplayer.so" dev="sda3" ino=1966220 scontext=unconfined_u:unconfined_r:mozilla_plugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:mozilla_plugin_rw_t:s0 tclass=file
May 21 14:54:00 localhost kernel: [ 7054.814098] type=1400 audit(1369162440.403:47): avc:  denied  { execute } for  pid=6373 comm="plugin-containe" path="/usr/lib64/mozilla/plugins-wrapped/nswrapper_32_64.libflashplayer.so" dev="sda3" ino=1966220 scontext=unconfined_u:unconfined_r:mozilla_plugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:mozilla_plugin_rw_t:s0 tclass=file
May 21 14:54:00 localhost kernel: [ 7054.814160] type=1400 audit(1369162440.403:48): avc:  denied  { execute } for  pid=6373 comm="plugin-containe" path="/usr/lib64/mozilla/plugins-wrapped/nswrapper_32_64.libflashplayer.so" dev="sda3" ino=1966220 scontext=unconfined_u:unconfined_r:mozilla_plugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:mozilla_plugin_rw_t:s0 tclass=file
Comment 8 Michael Wiktowy 2013-05-21 15:33:33 EDT
Forcing a relabel did *not* clear things up.

Switching SELinux into permissive mode instantly cleared up the issue. Doing some investigation leads to:

[root@desktop ~]# tail /var/log/messages |audit2why
May 21 15:25:19 localhost kernel: [  316.249038] type=1400 audit(1369164319.404:9): avc:  denied  { execute } for  pid=2671 comm="plugin-containe" path="/usr/lib64/mozilla/plugins-wrapped/nswrapper_32_64.libflashplayer.so" dev="sda3" ino=1966220 scontext=unconfined_u:unconfined_r:mozilla_plugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:mozilla_plugin_rw_t:s0 tclass=file

	Was caused by:
		Missing type enforcement (TE) allow rule.

		You can use audit2allow to generate a loadable module to allow this access.

[root@desktop ~]# tail /var/log/messages |audit2allow


#============= mozilla_plugin_t ==============
allow mozilla_plugin_t mozilla_plugin_rw_t:file execute;

Is this something that should be allowed or is the flash plug-in incorrectly labelled? Also, why did this show up with Firefox 21 and not the previous version. IIRC, the latest flash plugin update recent but was a lot longer ago than my last reboot/browser restart.
Comment 9 Martin Stransky 2013-05-21 17:38:49 EDT
IMHO there's some SELinux boolean which should be turned on for flash/pluginwrapper.
Comment 10 Michael Wiktowy 2013-05-24 03:04:27 EDT
If that is the case, I am wondering if some update turned it off since Firefox 20 and below worked fine.

There was an old "chcon -t textrel_shlib_t /usr/lib/flash-plugin/libflashplayer.so" fix but that looked like it caused something similar but I cannot find a boolean to tweak that seems relevant.
Comment 11 Rune Kleveland 2013-05-27 17:30:22 EDT
Downgrading firefox and xulrunner to firefox-20.0-5.fc18/xulrunner-20.0-4.fc18 from Koji seems to have resolved the issue for me on an up to date Fedora 18 x86_64.
Comment 12 Jan Horak 2013-05-28 06:51:33 EDT
Try to uninstall nspluginwrapper (if you don't need wrapped plugins) first. I'm getting similar Selinux reports too, like:

SELinux is preventing /usr/lib64/xulrunner/plugin-container from write access on the file cert9.db.

However I don't experience UI lockups.
Comment 13 Michael Wiktowy 2013-05-29 18:49:18 EDT
Downgrading to firefox-20.0-5.fc18.x86_64.rpm and xulrunner-20.0-4.fc18.x86_64.rpm from Koji worked for me as well. No more complaints from SELinux and no more freezing with no other changes other than a yum downgrade and a reboot. SELinux is set to "enforcing" again.

One thing that I did notice before downgrading was the flash player was not loading properly in that some videos on Youtube would indicate that the flash player was not found but the WebM/HTML5-ized ones would play fine. So Firefox 21 is not playing nicely with the flash plugin and/or plugin wrapper ... on my x86_64 system at least.

Now that I know I can work around the issue, I will see if removing nspluginwrapper will more ... however, I am under the impression that the flash plugin needs this glue, no?
Comment 14 Michael Wiktowy 2013-05-29 19:18:37 EDT
rpm -e nspluginwrapper-1.4.4-16.fc18.x86_64 removes the 64 bit portion of the nspluginwrapper (i have both the 64 bit and 32 bit version installed) and that causes the flash plugin not to be loaded (confirmed by about:plugins) and the problem goes away ... except that there are fewer Youtube videos to be seen. When I reinstall it, the flash plugin is loaded and everything locks up as soon as it is used for anything.

This only happens in Firefox 21 for me ... Firefox 20 loads the uses the plugin properly. I am not sure how Firefox 21 is using the same plugin and plugin-wrapper differently that causes SELinux to be unhappy.

It is consistently spitting out the error:

May 29 19:11:02 localhost kernel: [ 3294.127190] type=1400 audit(1369869062.520:13): avc:  denied  { execute } for  pid=4938 comm="plugin-containe" path="/usr/lib64/mozilla/plugins-wrapped/nswrapper_32_64.libflashplayer.so" dev="sda3" ino=1972558 scontext=unconfined_u:unconfined_r:mozilla_plugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:mozilla_plugin_rw_t:s0 tclass=file

and that causes Firefox 21 to lock up for me. I am uncertain why this is not more wide-spread unless no one uses enforcing mode :[.
Comment 15 Andy Lutomirski 2013-05-30 01:11:43 EDT
I had this problem, too.  The problem is that selinux is preventing nspluginwrapper from doing whatever magic it does.  (I personally think that selinux-policy's objection to allowing write and execute to the same thing is pointless, but that's neither here nor there.)

The fix is straightforward, though: if you have flash-plugin.i386 and adobe-release-i386 installed, remove them and install the 64-bit versions from:

http://get.adobe.com/flashplayer/completion/?installer=Flash_Player_11.2_for_other_Linux_(YUM)_64-bit

This works better than the 32-bit wrapped version ever did.
Comment 16 Martin Stransky 2013-05-30 01:45:06 EDT
Nspluginwrapper and plugin-container should not run in the same time - both do the same thing, run flash-plugin out of the main firefox process.

Which key/values (in about:config) do you have for "dom.ipc.plugins.enabled.nswrapper_32_64.libflashplayer.so" and other dom.ipc.plugins.* ones?
Comment 17 Michael Wiktowy 2013-05-30 23:11:20 EDT
The only dom.ipc.plugins.* keys that I have are:

dom.ipc.plugins.enabled;true
dom.ipc.plugins.flash.subprocess.crashreporter.enabled;true
dom.ipc.plugins.parentTimeoutSecs;0
dom.ipc.plugins.processLaunchTimeoutSecs;45
dom.ipc.plugins.reportCrashURL;true
dom.ipc.plugins.timeoutSecs;45

and they are all set to the default value according to config:about.
There does not seem to be any key pair listing "nswrapper" present.

Thank you Andy for the native 64 bit plugin suggestion. It wasn't working properly when I tried it way back went and I had thought that Adobe had abandoned efforts to develop that. I am happy to give it a try now as I know that the nswrapper thing is a bit of a cludge. If this works, it would be the proper solution. I am still confused as to what changed between Firefox 20 and 21 that triggered the wrapper not playing nicely with SELinux anymore.
Comment 18 Michael Wiktowy 2013-05-30 23:51:13 EDT
Uninstalling the 32-bit flash-plugin and the 32-bit Adobe yum repository (installed long long ago) and replacing it with the 64-bit versions poined out by Andy (which are also pointed to correctly on the Adobe website) now allows me to set SELinux to enforcing with no ill effects.

Both versions versions of nspluginwrapper is still installed due to a Citrix plugin needing them ... I suspect the dependencies are a little messed up since it is a 64-bit plugin ... and that will bite me when the time comes that I need that. But for the time being, things work better than ever.

Thanks for your help.
Comment 19 alfa_pub 2013-07-08 18:08:28 EDT
*** Bug 981737 has been marked as a duplicate of this bug. ***
Comment 20 Fedora End Of Life 2013-09-16 09:58:07 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 20 development cycle.
Changing version to '20'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora20
Comment 21 Fedora End Of Life 2015-05-29 05:04:18 EDT
This message is a reminder that Fedora 20 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 20. 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 EOL if it remains open with a Fedora  'version'
of '20'.

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.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 20 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, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

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.
Comment 22 Fedora End Of Life 2015-06-29 07:57:52 EDT
Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 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. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.