Firefox Acroread plugin not working

[Paul Howarth]

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.