On Sun, 2006-04-23 at 13:58 -0400, Gene Heskett wrote: > On Sunday 23 April 2006 13:36, Lauri wrote: > >> On Sunday 23 April 2006 12:51, Gene Heskett wrote: > >>> On Sunday 23 April 2006 10:23, Stanton Finley wrote: > >>>> On Sun, 2006-04-23 at 05:15 -0400, Gene Heskett wrote: > >>>>> On Sunday 23 April 2006 04:58, Chris Lale wrote: > >>>>>> Chris Lale wrote: > >>>>>>> I cannot view PDFs using Firefox in Etch (Testing). I get: > >>>>>>> > >>>>>>> "There was an error while loading the plugin - ewh.api. The > >>>>>>> plugin failed to initialize." > >>>>>>> > >>>>>>> I have these packages installed: > >>>>>>> > >>>>>>> acroread 7.0.5-0.0 > >>>>>>> mozilla-acroread 7.0.5-0.0 > >>>> > >>>> As root do a "yum -y remove acroread mozilla-acroread" and then > >>>> follow the instructions in the Adobe Reader section at > >>>> http://stanton-finley.net/fedora_core_5_installation_notes.html. > >>>> -- > >>>> Stanton Finley > >>>> http://stanton-finley.net/ > >>> > >>> And I forgot to note in the previous message that for some reason, > >>> selinux is disabling acroread unless set for permissive. This > >>> needs addressed also. I don't want to have to depend on a tail of > >>> the log to tell me when things are going in the toilet. > >> > >> To add more details, I have now read the manpage for selinux, > >> touched /.autorelabel and rebooted after setting selinux back to > >> enforcing. It did re-run the autolabeling function on the reboot. > >> > >> No change, an attempt to run acroread from the icon fails, and from > >> the cli, this message is output: > >> > >> [root@diablo ~]# acroread > >> /usr/local/Adobe/Acrobat7.0/Reader/intellinux/bin/acroread: error > >> while loading shared > >> libraries: > >> /usr/local/Adobe/Acrobat7.0/Reader/intellinux/lib/libJP2K.so: cannot > >> restore segment prot after reloc: Permission denied > >> > >> I've investigated the system-config-securitylevel thing, which FWIW > >> thought it was in the enforcing mode when /etc/selinux/config said > >> otherwise, so thats obviously broken right there, and went thru the > >> menu's looking for something to check or uncheck but didn't find any > >> 'suspects' that might control the above. > >> > >> This subject has been noted, at some length now in this and similar > >> threads, with no one offering a helpfull comment so far. Is this > >> something that only the NSA can answer? Or is there an FM I haven't > >> read because I don't know of its existance so I can do the RT > >> portion? > > > ># chcon -t texrel_shlib_t > >/usr/local/Adobe/Acrobat7.0/Reader/intellinux/lib/*.so > > > >Lauri > > Thank you very much Lauri, that worked like a champ. But why does it > seem to be such a huge secret other than its ulitmately being usefull > to the blackhats? It's no big secret - this issue and this solution has come up on this list many times: http://www.google.com/search?q=fedora-list+acroread+texrel_shlib_t or http://www.google.com/search?q=fedora-list+acroread+textrel_shlib_t (note that textrel_shlib_t is the correct type but texrel_shlib_t is an alias for it) > I assume that this command line (the top line above) can be used against > any other known good (we think) but similarly malfunctioning (the > bottom line above) program? In many cases, yes. See the FC5 SELinux FAQ: http://fedora.redhat.com/docs/selinux-faq-fc5/ (Q: I have a process running as unconfined_t, and SELinux is still preventing my application from running.) The reason why this problem crops up so much with proprietary software is that the software is released in a very generic fashion so as to work on as many different distributions as possible. This is usually done by building it on an old distro like Red Hat 7.x so that the resulting packages will require only long-established glibc functionality, which is still supported by modern distributions (and hence no deps on more recent libraries). Unfortunately, the compiler/linker on the old distributions doesn't distinguish between the different memory areas of the resulting executable clearly (e.g. stack, code, writable data areas), so when it comes to execute on FC5, it appears to be trying to execute code from a writable area of memory (or worse, a stack segment), and SELinux doesn't allow that by default. Now the SELinux policy developers know about this issue and did actually try to stop it coming up, at least in the case of nvidia drivers and acrobat reader, by having the files get installed with the right context in the first place: # semanage fcontext -l | grep -Ei 'nvidia|acrobat' /usr(/.*)?/nvidia/.*\.so(\..*)? regular file system_u:object_r:textrel_shlib_t:s0 /usr/lib(64)?(/.*)?/nvidia_drv.*\.so(\.[^/]*)* regular file system_u:object_r:textrel_shlib_t:s0 /usr/lib(64)?(/.*)?/libnvidia.*\.so(\.[^/]*)* regular file system_u:object_r:textrel_shlib_t:s0 /usr/lib(64)?/(nvidia/)?libGL(core)?\.so(\.[^/]*)* regular file system_u:object_r:textrel_shlib_t:s0 /usr/X11R6/lib/libXvMCNVIDIA\.so.* regular file system_u:object_r:textrel_shlib_t:s0 /dev/nvidia.* character device system_u:object_r:xserver_misc_device_t:s0 Unfortunately this hasn't worked because some things have been missed. However, raising the issue on fedora-selinux-list or bugzilla, specifying exactly what you needed to do to resolve the problem, would likely result in an updated policy being pushed before too long that fixed this problem for everybody and then this rather FAQ would hopefully stop cropping up so often. Will someone using nvidia drivers/acrobat reader please do this? Paul.
