Firefox Acroread plugin not working

[Paul Howarth]

Gene Heskett wrote:
> On Monday 24 April 2006 16:27, Paul Howarth wrote:
> [...]
>>> Where does one find this info since java normally runs silently?  I
>>> have copied the java ns7 plugin to the firefox plugins dir, but its
>>> still not found, and running firefox from the shell and doing an
>>> about:plugins leaves a blank shell when firefox is then quit.
>> You might find selinux denial messages in /var/log/messages - search
>> for the string "avc:  denied" (note the two spaces after the colon).
>> You can also check to make sure it's an SELinux problem by doing
>> "setenforce 0" and see if there's still a problem.
>>
>> You might also try my Java HOWTO:
>> http://www.city-fan.org/tips/JpackageJava
> 
> I followed that, and the first mistake I'd made was in getting the one 
> with netbeans included, which didn't fly at all. I should have known 
> when it was 127 megabytes it was the wrong one, but...
> 
> Then once I'd fetched the right file and stepped thru all the procedures 
> in your link above, includeing almost an hour to get 2 of the 3 new 
> filelists yum needed to get while executing yum-com, and an equally 
> slow download of the OBDC stuff, it eventually said it was done with an 
> exit 0.  Then I cleaned up the links and files in the plugins dirs, 
> loaded filefox both as root and as a common user, and voila!  
> about:plugins now reports a whole screenfull of java stuff.

Splendid!

You could actually have saved on the OBDC download by not installing the 
particular java package that required it - as long as you know you're 
not going to need it - but it keeps things simpler just to install 
everything.

> The only place I'll fault the instructions in the above link is that in 
> the case of FC5, one must change the use of the ~/downloads directory 
> quoted every so often to be /usr/src/redhat in actual fact, then 
> everything Just Works(TM).

Hmm, the ~/download directory just represents wherever your browser puts 
stuff you've downloaded (sometimes that would be ~/Desktop).

/usr/src/redhat is a very strange place for that to be since that's only 
writable by root. You don't run a browser as root do you?

> And I have yet another very big grin on my face for a few minutes, till 
> I run into the next showstopper anyway.
> 
> Which isn't this, but this is a slight worry from the log:
> 
> Apr 24 21:34:07 diablo kernel: hdc: cdrom_pc_intr: The drive appears 
> confused (ireason = 0x01)
> Apr 24 21:34:09 diablo kernel: hdc: cdrom_pc_intr: The drive appears 
> confused (ireason = 0x01)
> 
> There is no disk in the drive, and its been reading disks just fine.

Could be a hardware issue.
http://lists.xiph.org/pipermail/paranoia/2004-May/001271.html

>>> Now, maybe I'm slow this morning, but my reading of the semanage
>>> manpage makes no mention of setting a 'default' that a relabel will
>>> leave alone.
>> Using semanage you can change policy for file contexts amongst other
>> things. This affects the contexts applied to files using restorecon
>> etc.
> 
> Are you saying that if I change it with chcon, its temporary, but if I 
> change it with semanage its permanent?
> 
> 'scuse me, but these manpages suck dead toads through soda straws! 
> (Thats plagerizing a longtime friend of mine you all know)
> They seriously need a rewrite in much plainer language.  These are 
> concise to the point of obtuse.  WTDO=Way Too Damned Obtuse.

Have to agree there.

SELinux file contexts get set in one of two ways.

1. By an SELinux-aware application manually setting the context based on 
the pathname of the object concerned. This is, for example, what rpm 
does when new packages are installed, and it uses the file contexts 
configured in the SELinux policy you're using. The command "semanage 
fcontext -l" lists a bunch of regular expressions matching pathnames, 
which rpm searches to find the correct context to use for each 
file/directory etc. being installed. The same process happens if you use 
"restorecon" or relabel the entire system.

2. By the kernel when a file/directory etc. is created. This does not 
use pathnames at all; instead, the context is based on the SELinux 
domain that the process is running in and the file context of the inode 
for the directory that the item is to be created in. The contexts to be 
used in these cases are defined in the SELinux policy and can be changed 
by building and installing an SELinux policy module. But that's outside 
the scope of this discussion.

The latter is the "normal" and "preferred" way to establish contexts 
because pathname-based contexts are a bad idea generally (e.g. supposing 
you have multiple links to the same file using different paths - which 
should be used to set the context?). The former method is there so that 
an initial sane state can be created or reverted to in the event of 
policy changes, cock-ups etc.

So, what you're doing with "chcon" is manually setting file context, 
just like rpm would do, except you're setting the context to the value 
you believe to be correct instead of the one the policy writer believes 
to be correct. Since the policy writer may be ignorant of your 
requirements, this is a good thing.

How, when you do a "restorecon" or "relabel", what you're doing is 
saying "I've got a bunch of files with contexts that may or may not be 
correct fow whatever reason, and I'd like them restored to the system 
default context". So that overrides the changes you made manually using 
"chcon". Well, actually that doesn't happen if the type you've used is 
defined as a "customisable type" - that will not be touched, but that's 
a side issue here.

Now if you're really sure that you've got the right contexts, you can 
actually change the policy itself so that a "restorecon" or "relabel" 
will restore the contexts to the ones you've specified. This is done 
using semanage to add additional file context objects to the policy. It 
doesn't change any file contexts itself, it just sets up the defaults 
that will be used if "restorecon" is used or you relabel the system.

Paul.