Firefox Acroread plugin not working

[Gene Heskett]

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 at 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.