Firefox Acroread plugin not working

[Paul Howarth]

Gene Heskett wrote:
> On Tuesday 25 April 2006 07:50, Paul Howarth wrote:
> 
> [...]
> 
>>> 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?
> 
> Yes and no, mostly yes.  But I'm behind a pretty bulletproof firewall 
> here at home too.  The whole point was that I had to move it there 
> because the make script generated was apparently hard coded to look for 
> its stuff in /usr/src/redhat/RPMS,SOURCE etc, tree that was reported by 
> the dying build, and that was already pre-constructed by the FC5 
> install. It wouldn't build if not there, and I don't know if being
> root or not, I was, would have effected that outcome.  So I just moved 
> it all to where it wanted it to be.  The end result also works fine as 
> uid 500 too.

It is because you ran it as root. The instructions actually go to some 
length to support building the package as a non-root user, and in fact 
the linked page on creating an RPM-build environment mentions some 
reasons why building packages as root is a bad idea.

In this case the result is the same and no harm is done, but I'd try to 
avoid that in future and in fact do as little as possible as root, 
regardless of how good your firewall is.

>>> '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.
> 
> Who wrote them?, I wanna throw something at that person.

IIRC one of the things the author did actually manage to include was his 
name :-)

>> 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.
> 
> Not to mention outside my ken.
> 
>> 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.
> 
> And you obviously have a much better grasp of this than I, thanks to 
> those wholely inadequate manpages. :(

I only grasped this myself fairly recently. However, the FC5 SELinux 
documentation is a vast improvement on that available for earlier 
releases, at least if you know where to look for it.

http://fedoraproject.org/wiki/SELinux is a decent starting point.

Paul.

> 
>> Paul.
>