Firefox Acroread plugin not working

[Gene Heskett]

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.

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

Who wrote them?, I wanna throw something at that person.

>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. :(

>Paul.

-- 
Cheers Paul, 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.