On Monday 24 April 2006 04:01, Paul Howarth wrote: >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. >From previous remarks made in this and similar threads, I'm wondering about the java J2SE I'm currently downloading to that FC5 lappy. In that event, is the correct chcon command: chcon -t texrel_shlib_t /path/to/directory_of_library_being_complained_about/*.so -- Cheers, Gene People having trouble with vz bouncing email to me should add the word 'online' between the 'verizon', and the dot which bypasses vz's stupid bounce rules. I do use spamassassin too. :-) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2006 by Maurice Eugene Heskett, all rights reserved.
