Description of problem: The combination of plugin-container & the flash plugin causes page loads to hang (presumably hitting the 45 second timeout). This occurs on a F-16 upgraded system. It did not happen on F-15, despite the versions of FF/XR being materially the same. Happens with flash 10 (64-bit), flash 11 (64-bit) and nspluginwrapper-wrapped flash-10 (32-bit) Version-Release number of selected component (if applicable): firefox-5.0-2.fc16.x86_64 xulrunner-5.0-5.fc16.x86_64 glibc-2.14.90-4.x86_64 How reproducible: 100% Steps to Reproduce: 1. Enable flash plugin and dom.ipc.plugins.enabled 2. Go to a flash page Actual results: Watch Firefox freeze for quite a while. Expected results: Not that. Additional info: Backtraces of FF & plugin-container threads aren't obviously useful - poll(), pthread_cond_wait, epoll().
Could you suggest some specific page? Youtube is now mostly HTML5 for me, I tried also vimeo, but neither there nor there I saw any significant delays. Is it more about flash video sites, or some specific application (i.e., flash more like a programming environment)? It means I have to ask for normal Firefox troubleshooting routine: 1) Are you able to reproduce this when running firefox with all addons disabled? 2) Are you able to reproduce the problem with the upstream binary from http://www.firefox.com/? 3) Are you able to reproduce the problem with a fresh profile? Thanks in advance.
Embedded video links with youtube's flash player is where I noticed it most often. With respect to the questions: 1) Not sure how to parse this. I obviously can't reproduce a hang with the flash plugin when the flash plugin is disabled, but not sure that helps. If I turn off the plugin container code, flash doesn't cause a delay. (Of course, it then takes the entire process down when it crashes. Tradeoffs...) 2) Haven't tried yet. 3) Yes.
Clarification on #1 - it still happens when disabling all add-ons, and all plugins except flash.
Doesn't happen with upstream FF when installed in my homedir, but if it's moved to the system directory, it does. Turns out it's SELinux. audit2allow in permissive mode implies: #============= mozilla_plugin_t ============== allow mozilla_plugin_t unconfined_t:sem { read unix_read write unix_write associate }; allow mozilla_plugin_t unconfined_t:shm { write unix_read getattr unix_write associate read destroy }; is needed.
Miroslav add allow mozilla_plugin_t $1:shm rw_shm_perms; allow mozilla_plugin_t $1:sem create_sem_perms; To mozilla_run_plugin
Fixed in selinux-policy-3.10.0-15.fc16
No, it isn't. my bug #717087 is the same as this, we should dupe one of them off. This still happens with selinux-policy -18, for me. As I noted in my bug, this affects all Flash plugins - or at least Adobe 10, Adobe 11, and gnash.
I don't seem to get any selinux alerts, although there is an odd message in /var/log/messages : Aug 16 12:57:10 adam setroubleshoot: [avc.ERROR] Plugin Exception catchall_labels #012Traceback (most recent call last):#012 File "/usr/lib64/python2.7/site-packages/setroubleshoot/analyze.py", line 191, in analyze_avc#012 report = plugin.analyze(avc)#012 File "/usr/share/setroubleshoot/plugins/catchall_labels.py", line 53, in analyze#012 return self.report(avc.allowed_target_types())#012 File "/usr/lib64/python2.7/site-packages/setroubleshoot/audit_data.py", line 676, in allowed_target_types#012 return map(lambda x: x[TCONTEXT], sesearch([ALLOW], {SCONTEXT: self.scontext.type, CLASS: self.tclass, PERMS: self.access}))#012 File "/usr/lib64/python2.7/site-packages/setroubleshoot/sesearch/__init__.py", line 30, in sesearch#012 dict_list = _sesearch.search(info)#012SystemError: NULL object passed to Py_BuildValue around the time I started Firefox with selinux in Enforcing mode. But it's definitely still this bug. No delays and Flash works in Permissive mode, 45 second delay and Flash fails in Enforcing. I'm on Flash 11B1 atm.
Bug #729707 is also this.
Dan seems to think it'll be fixed in -19, based on a comment in that bug.
Fixed in selinux-policy-3.10.0-19.fc16
selinux-policy-3.10.0-21.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/selinux-policy-3.10.0-21.fc16
Package selinux-policy-3.10.0-21.fc16: * should fix your issue, * was pushed to the Fedora 16 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.10.0-21.fc16' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/selinux-policy-3.10.0-21.fc16 then log in and leave karma (feedback).
selinux-policy-3.10.0-21.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.