From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20051215 Epiphany/1.9.4 Description of problem: Upon installation of "flash-plugin-7.0.61-1", associated media cannot be displayed. Web browsers behave as if the plugin had not been installed. Version-Release number of selected component (if applicable): selinux-policy-targeted-2.1.7-3 How reproducible: Always Steps to Reproduce: 1. Install "flash-plugin". 2. Launch "epiphany" etc. 3. Go to a web page with embedded "flash" elements. Actual Results: The "flash" elements are not rendered as expected. The corresponding part of the window remains empty. Upon clicking inside it, one is invited to install the corresponding missing plugin. Expected Results: "flash" elements should get rendered correctly. Additional info: Execution of "chcon system_u:object_r:texrel_shlib_t /usr/lib/flash-plugin/libflashplayer.so" allows to recover "flash" functionality. Other plugins are also affected, e.g. "java" and "realplayer" plugins.
Still not fixed in "selinux-policy-targeted-2.1.9-2".
Fixed in 2.1.10-2
After a fresh install from the development tree issue found to be not fixed in "selinux-policy-targeted-2.2.2-1".
Something has changed however in the sense that now the "chcon system_u:object_r:texrel_shlib_t SH_LIB" trick does not work anymore.
Are you seeing new avc messages? If you do the following, what do you see? restorecon /usr/lib/flash-plugin/libflashplayer.so ls -lZ /usr/lib/flash-plugin/libflashplayer.so
*** Bug 178617 has been marked as a duplicate of this bug. ***
Before: ls -lZ /usr/lib/flash-plugin/libflashplayer.so -rwxr-xr-x root root system_u:object_r:textrel_shlib_t /usr/lib/flash-plugin/libflashplayer.so Execute: restorecon /usr/lib/flash-plugin/libflashplayer.so After: ls -lZ /usr/lib/flash-plugin/libflashplayer.so -rwxr-xr-x root root system_u:object_r:textrel_shlib_t /usr/lib/flash-plugin/libflashplayer.so
Ok so that is correct. Are you seeing avc messages in /var/log/audit/audit.log pr /var/log/messages?
Sure there are but nothing relevant. Only "denied" entries related to "readahead", "mount" and similar. On the contrary to FC5 test1, I have problems with other 3rd party shared libraries again, and the "chcon" trick does not help anymore: "xpdf: error while loading shared libraries: libXm.so.2: cannot enable executable stack as shared object requires: Permission denied" Here, "libXm.so.2" is an older version of the "Motif" runtime library. Current "SELinux" rules version is "selinux-policy-targeted-2.2.4-1". No "Flash", no "Java", etc. Frustrating.
You can turn on the booleans allow_execmem allow_execmod Which should allow them to run. But you should be seeing avc messages on libXm.so and others. How is this file labeled? Could you attach your audit.log ?
None of both mentioned variables allowed to run "xpdf". However, while I was browsing through "/selinux/booleans", I discovered "allow_execstack" which looked more promising having in mind the complaint ".. cannot enable executable stack ..". Bingo! After executing "setsebool -P allow_execstack=1", "xpdf" starts up as expected, and even the browser plugins work! The problem apparently did not stem from the file context, but from the fact, that those guys require an executable stack.
To be more precise, "allow_execmem=1" is also required, "allow_execmod=1" is additionally needed for the "java" plugin. The "audit.log" does not reveal anything relevant to my eyes but I attach it anyway.
Created attachment 123725 [details] Audit subsystem log file
Epiphany requires execstack. This is a bad thing. http://people.redhat.com/drepper/selinux-mem.html
Was this fixed by the nss update? https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180726
Plugins do work again because "allow_execstack" has been reenabled by default in "SELinux". After executing "setsebool -P allow_execstack 0", however, plugins fail as at the time when I opened this bug report. Consequently, the answer is no.
Did anybody use the execstack tool to simply reset the flag in the plugins? I.e., use exestack -c /path/to/plugin Then try again. My guess is that it's simply the build process which is broken. They either use old object files or asm files without the necessary magic.
Since this bugzilla report was filed, we have seriously upgraded Gecko-related packages in Rawhide, which may have resolved this issue. Users who have experienced this problem are encouraged to upgrade their system to the latest version of their distribution available. Closing this bug as CANTFIX. Please, reopen, if this bug is still reproducable on the latest update of your distribution. [This is mass-closing of bugs which seem to be too old and irrelevant anymore; we are sorry, if we are closing your bug in mistake; please, don't hesitate to reopen, if it is still alive issue.]