Bug 491229 - SELinux prevents Google Earth from running, and following the troubleshooter instructions fails
SELinux prevents Google Earth from running, and following the troubleshooter ...
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted (Show other bugs)
10
i686 Linux
low Severity high
: ---
: ---
Assigned To: Miroslav Grepl
Ben Levenson
:
: 504718 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-03-19 18:29 EDT by Joe Zeff
Modified: 2009-11-18 05:22 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-11-18 05:22:23 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
SELinux troubleshooter output (3.17 KB, text/plain)
2009-03-19 18:29 EDT, Joe Zeff
no flags Details

  None (edit)
Description Joe Zeff 2009-03-19 18:29:11 EDT
Created attachment 335938 [details]
SELinux troubleshooter output

Description of problem:

I try to launch Google Earth and it's prevented by SELinux.  I follow the instructions to correct the problem but it just happens again.

Version-Release number of selected component (if applicable):


How reproducible:

For me, it happens every time

Steps to Reproduce:
1.Launch Google Earth
2.Follow the instructions in the SELinux troubleshooter
3.Launch Google Earth and watch the same thing happen again.
  
Actual results:

Google Earth fails to start

Expected results:

Google Earth launches

Additional info:
Comment 1 Joe Zeff 2009-03-19 19:11:59 EDT
I would have entered this as a bug of googleearth, but it's not in the list of Fedora programs.  I selected SELinux targeted because the error message referred to a targeted policy.  Feel free to move the bug around as needed to get it in the right place.
Comment 2 Daniel Walsh 2009-03-20 13:49:30 EDT
Joe googlearth is not a Fedora package.  So you should report this bug to google.

chcon -R -t textrel_shlib_t /usr/lib/googlearth

Should fix the problem.

Tell google they need to build their libraries correctly, with the proper PIC flags.

And give them this link

http://people.redhat.com/~drepper/selinux-mem.html
Comment 3 Joe Zeff 2009-03-20 14:34:56 EDT
Thank you.  When I tried to follow your suggestion, bash told me that there was no such file or directory.  A little checking found that the directory in question is /usr/lib/googleearth, and that worked.  The reason I brought it here first is because SELinux recommended a fix that didn't work, so it might have been a problem there.  I also figured that if it weren't, you'd at least point me in the right direction, and (with help from fedoraforum.org) I could work it out on my own.

Again, thanx for the assistance, and I'll take your advice about letting Google know about this.
Comment 4 Miroslav Grepl 2009-03-23 13:22:45 EDT
Fixed in selinux-policy-3.5.13-51.fc10
Comment 5 Joe Zeff 2009-03-23 13:41:39 EDT
Again, thank you.  There seems to be no way to discuss things like this directly with the Google developers, just a help group at Google Groups.  A search of the group reveals that people have been butting their heads against this since, at least, November,2008.  I hope that other distros will follow suit.
Comment 6 Charles McGowen 2009-08-02 14:15:56 EDT
I have exactly the same problem.  As you can see the latest update to Fedora 11 SELinux Targeted policy makes no difference and the problem remains.  Google Earth will not load.  Only minutes prior to getting this error I updated my installation with the latest updates to all modules.  The recommendation command below does not fix the problem nor does it allow for a work around.


Summary:

SELinux is preventing googleearth-bin from loading
/opt/google-earth/libminizip.so which requires text relocation.

Detailed Description:

The googleearth-bin application attempted to load
/opt/google-earth/libminizip.so which requires text relocation. This is a
potential security problem. Most libraries do not need this permission.
Libraries are sometimes coded incorrectly and request this permission. The
SELinux Memory Protection Tests
(http://people.redhat.com/drepper/selinux-mem.html) web page explains how to
remove this requirement. You can configure SELinux temporarily to allow
/opt/google-earth/libminizip.so to use relocation as a workaround, until the
library is fixed. Please file a bug report
(http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against this package.

Allowing Access:

If you trust /opt/google-earth/libminizip.so to run correctly, you can change
the file context to textrel_shlib_t. "chcon -t textrel_shlib_t
'/opt/google-earth/libminizip.so'" You must also change the default file context
files on the system in order to preserve them even on a full relabel. "semanage
fcontext -a -t textrel_shlib_t '/opt/google-earth/libminizip.so'"

Fix Command:

chcon -t textrel_shlib_t '/opt/google-earth/libminizip.so'

Additional Information:

Source Context                unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1
                              023
Target Context                unconfined_u:object_r:usr_t:s0
Target Objects                /opt/google-earth/libminizip.so [ file ]
Source                        googleearth-bin
Source Path                   /opt/google-earth/googleearth-bin
Port                          <Unknown>
Host                          IBM623041UKPH2487.SolREI.com
Source RPM Packages           
Target RPM Packages           
Policy RPM                    selinux-policy-3.6.12-69.fc11
Selinux Enabled               True
Policy Type                   targeted
MLS Enabled                   True
Enforcing Mode                Enforcing
Plugin Name                   allow_execmod
Host Name                     IBM623041UKPH2487.SolREI.com
Platform                      Linux IBM623041UKPH2487.SolREI.com
                              2.6.29.6-213.fc11.i586 #1 SMP Tue Jul 7 20:45:17
                              EDT 2009 i686 i686
Alert Count                   6
First Seen                    Sun 02 Aug 2009 01:42:14 PM EDT
Last Seen                     Sun 02 Aug 2009 02:10:38 PM EDT
Local ID                      62548c86-c198-46da-915a-6129648ccaca
Line Numbers                  

Raw Audit Messages            

node=IBM623041UKPH2487.SolREI.com type=AVC msg=audit(1249236638.812:30323): avc:  denied  { execmod } for  pid=13285 comm="googleearth-bin" path="/opt/google-earth/libminizip.so" dev=dm-0 ino=5911780 scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:usr_t:s0 tclass=file

node=IBM623041UKPH2487.SolREI.com type=SYSCALL msg=audit(1249236638.812:30323): arch=40000003 syscall=125 success=no exit=-13 a0=3dd000 a1=6000 a2=5 a3=bf886c40 items=0 ppid=1 pid=13285 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) ses=1 comm="googleearth-bin" exe="/opt/google-earth/googleearth-bin" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)
Comment 7 Charles McGowen 2009-08-02 14:24:36 EDT
I just sent a note to Google using this Survey form:

https://earth.google.com/support/bin/request.py?contact_type=survey

and referenced this bug ID on Bugzilla.  Strongly suggest everyone do the same thing.  There is more power in numbers......  (e.g. squeaky wheel gets the grease)  [ so squeak'em....]
Comment 8 Charles McGowen 2009-08-02 14:55:20 EDT
The above error is the error I get at the end of the install process when the program asks if you would like to start Google Earth.  It fails that way every time regardless of running the command and rerunning the install process.  I can understand that on the first pass.  However if the chcon command theoretically fixes the problem it should not encounter it on the second install pass - yet it does.

Now if I ignore the above problem and blow it off as an install glitch and execute the Google Earth program from the menu then I get a series of incremental errors.

Due to the volume of information I will attach each error as an independent comment and let you know the sequence number in the chain of executions for my situation:
Comment 9 Charles McGowen 2009-08-02 14:57:28 EDT
1st Error in Sequence.  Fix Command executed




Summary:

SELinux is preventing googleearth-bin from loading
/opt/google-earth/librender.so which requires text relocation.

Detailed Description:

The googleearth-bin application attempted to load /opt/google-earth/librender.so
which requires text relocation. This is a potential security problem. Most
libraries do not need this permission. Libraries are sometimes coded incorrectly
and request this permission. The SELinux Memory Protection Tests
(http://people.redhat.com/drepper/selinux-mem.html) web page explains how to
remove this requirement. You can configure SELinux temporarily to allow
/opt/google-earth/librender.so to use relocation as a workaround, until the
library is fixed. Please file a bug report
(http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against this package.

Allowing Access:

If you trust /opt/google-earth/librender.so to run correctly, you can change the
file context to textrel_shlib_t. "chcon -t textrel_shlib_t
'/opt/google-earth/librender.so'" You must also change the default file context
files on the system in order to preserve them even on a full relabel. "semanage
fcontext -a -t textrel_shlib_t '/opt/google-earth/librender.so'"

Fix Command:

chcon -t textrel_shlib_t '/opt/google-earth/librender.so'

Additional Information:

Source Context                unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1
                              023
Target Context                unconfined_u:object_r:usr_t:s0
Target Objects                /opt/google-earth/librender.so [ file ]
Source                        googleearth-bin
Source Path                   /opt/google-earth/googleearth-bin
Port                          <Unknown>
Host                          IBM623041UKPH2487.SolREI.com
Source RPM Packages           
Target RPM Packages           
Policy RPM                    selinux-policy-3.6.12-69.fc11
Selinux Enabled               True
Policy Type                   targeted
MLS Enabled                   True
Enforcing Mode                Enforcing
Plugin Name                   allow_execmod
Host Name                     IBM623041UKPH2487.SolREI.com
Platform                      Linux IBM623041UKPH2487.SolREI.com
                              2.6.29.6-213.fc11.i586 #1 SMP Tue Jul 7 20:45:17
                              EDT 2009 i686 i686
Alert Count                   1
First Seen                    Sun 02 Aug 2009 02:50:08 PM EDT
Last Seen                     Sun 02 Aug 2009 02:50:08 PM EDT
Local ID                      aff61c22-e8ff-46f1-94fa-e8a4f7c3916d
Line Numbers                  

Raw Audit Messages            

node=IBM623041UKPH2487.SolREI.com type=AVC msg=audit(1249239008.609:30329): avc:  denied  { execmod } for  pid=13525 comm="googleearth-bin" path="/opt/google-earth/librender.so" dev=dm-0 ino=5911789 scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:usr_t:s0 tclass=file

node=IBM623041UKPH2487.SolREI.com type=SYSCALL msg=audit(1249239008.609:30329): arch=40000003 syscall=125 success=no exit=-13 a0=6bce000 a1=95000 a2=5 a3=bfd64b10 items=0 ppid=1 pid=13525 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) ses=1 comm="googleearth-bin" exe="/opt/google-earth/googleearth-bin" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)
Comment 10 Charles McGowen 2009-08-02 14:59:05 EDT
2nd Error in Sequence.  Fix Command Executed:


Summary:

SELinux is preventing googleearth-bin from loading /opt/google-earth/libauth.so
which requires text relocation.

Detailed Description:

The googleearth-bin application attempted to load /opt/google-earth/libauth.so
which requires text relocation. This is a potential security problem. Most
libraries do not need this permission. Libraries are sometimes coded incorrectly
and request this permission. The SELinux Memory Protection Tests
(http://people.redhat.com/drepper/selinux-mem.html) web page explains how to
remove this requirement. You can configure SELinux temporarily to allow
/opt/google-earth/libauth.so to use relocation as a workaround, until the
library is fixed. Please file a bug report
(http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against this package.

Allowing Access:

If you trust /opt/google-earth/libauth.so to run correctly, you can change the
file context to textrel_shlib_t. "chcon -t textrel_shlib_t
'/opt/google-earth/libauth.so'" You must also change the default file context
files on the system in order to preserve them even on a full relabel. "semanage
fcontext -a -t textrel_shlib_t '/opt/google-earth/libauth.so'"

Fix Command:

chcon -t textrel_shlib_t '/opt/google-earth/libauth.so'

Additional Information:

Source Context                unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1
                              023
Target Context                unconfined_u:object_r:usr_t:s0
Target Objects                /opt/google-earth/libauth.so [ file ]
Source                        googleearth-bin
Source Path                   /opt/google-earth/googleearth-bin
Port                          <Unknown>
Host                          IBM623041UKPH2487.SolREI.com
Source RPM Packages           
Target RPM Packages           
Policy RPM                    selinux-policy-3.6.12-69.fc11
Selinux Enabled               True
Policy Type                   targeted
MLS Enabled                   True
Enforcing Mode                Enforcing
Plugin Name                   allow_execmod
Host Name                     IBM623041UKPH2487.SolREI.com
Platform                      Linux IBM623041UKPH2487.SolREI.com
                              2.6.29.6-213.fc11.i586 #1 SMP Tue Jul 7 20:45:17
                              EDT 2009 i686 i686
Alert Count                   1
First Seen                    Sun 02 Aug 2009 02:56:46 PM EDT
Last Seen                     Sun 02 Aug 2009 02:56:46 PM EDT
Local ID                      de0e5751-9fba-45ef-b06e-b7faf07cb9e4
Line Numbers                  

Raw Audit Messages            

node=IBM623041UKPH2487.SolREI.com type=AVC msg=audit(1249239406.510:30334): avc:  denied  { execmod } for  pid=13586 comm="googleearth-bin" path="/opt/google-earth/libauth.so" dev=dm-0 ino=5911742 scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:usr_t:s0 tclass=file

node=IBM623041UKPH2487.SolREI.com type=SYSCALL msg=audit(1249239406.510:30334): arch=40000003 syscall=125 success=no exit=-13 a0=6e7000 a1=92000 a2=5 a3=bf9a1300 items=0 ppid=1 pid=13586 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) ses=1 comm="googleearth-bin" exe="/opt/google-earth/googleearth-bin" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)
Comment 11 Charles McGowen 2009-08-02 15:01:11 EDT
Note: Google Earth logo panel briefly displays at this point but does not remain as the program tries to load.

3rd Sequence Error.  Fix Command Executed.


Summary:

SELinux is preventing googleearth-bin from loading /opt/google-earth/libevll.so
which requires text relocation.

Detailed Description:

The googleearth-bin application attempted to load /opt/google-earth/libevll.so
which requires text relocation. This is a potential security problem. Most
libraries do not need this permission. Libraries are sometimes coded incorrectly
and request this permission. The SELinux Memory Protection Tests
(http://people.redhat.com/drepper/selinux-mem.html) web page explains how to
remove this requirement. You can configure SELinux temporarily to allow
/opt/google-earth/libevll.so to use relocation as a workaround, until the
library is fixed. Please file a bug report
(http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against this package.

Allowing Access:

If you trust /opt/google-earth/libevll.so to run correctly, you can change the
file context to textrel_shlib_t. "chcon -t textrel_shlib_t
'/opt/google-earth/libevll.so'" You must also change the default file context
files on the system in order to preserve them even on a full relabel. "semanage
fcontext -a -t textrel_shlib_t '/opt/google-earth/libevll.so'"

Fix Command:

chcon -t textrel_shlib_t '/opt/google-earth/libevll.so'

Additional Information:

Source Context                unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1
                              023
Target Context                unconfined_u:object_r:usr_t:s0
Target Objects                /opt/google-earth/libevll.so [ file ]
Source                        googleearth-bin
Source Path                   /opt/google-earth/googleearth-bin
Port                          <Unknown>
Host                          IBM623041UKPH2487.SolREI.com
Source RPM Packages           
Target RPM Packages           
Policy RPM                    selinux-policy-3.6.12-69.fc11
Selinux Enabled               True
Policy Type                   targeted
MLS Enabled                   True
Enforcing Mode                Enforcing
Plugin Name                   allow_execmod
Host Name                     IBM623041UKPH2487.SolREI.com
Platform                      Linux IBM623041UKPH2487.SolREI.com
                              2.6.29.6-213.fc11.i586 #1 SMP Tue Jul 7 20:45:17
                              EDT 2009 i686 i686
Alert Count                   1
First Seen                    Sun 02 Aug 2009 02:59:30 PM EDT
Last Seen                     Sun 02 Aug 2009 02:59:30 PM EDT
Local ID                      d4b40597-e219-4ea5-99f1-b7c2aeab7781
Line Numbers                  

Raw Audit Messages            

node=IBM623041UKPH2487.SolREI.com type=AVC msg=audit(1249239570.213:30335): avc:  denied  { execmod } for  pid=13606 comm="googleearth-bin" path="/opt/google-earth/libevll.so" dev=dm-0 ino=5911750 scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:usr_t:s0 tclass=file

node=IBM623041UKPH2487.SolREI.com type=SYSCALL msg=audit(1249239570.213:30335): arch=40000003 syscall=125 success=no exit=-13 a0=4bb5000 a1=85e000 a2=5 a3=bfaf1850 items=0 ppid=1 pid=13606 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) ses=1 comm="googleearth-bin" exe="/opt/google-earth/googleearth-bin" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)
Comment 12 Charles McGowen 2009-08-02 15:34:50 EDT
4th - 11th Sequence Errors.  Rather than enter all of these I'm simply going to list the Fix Commands recommended by SELinux:

01: chcon -t textrel_shlib_t '/opt/google-earth/libminizip.so'
02: chcon -t textrel_shlib_t '/opt/google-earth/librender.so'
03: chcon -t textrel_shlib_t '/opt/google-earth/libauth.so'
04: chcon -t textrel_shlib_t '/opt/google-earth/libevll.so'
05: chcon -t textrel_shlib_t '/opt/google-earth/libcollada.so'
06: chcon -t textrel_shlib_t '/opt/google-earth/libgps.so'
07: chcon -t textrel_shlib_t '/opt/google-earth/libbasicingest.so'
08: chcon -t textrel_shlib_t '/opt/google-earth/libmeasure.so'
09: chcon -t textrel_shlib_t '/opt/google-earth/libflightsim.so'
10: chcon -t textrel_shlib_t '/opt/google-earth/libinput_plugin.so'
11: chcon -t textrel_shlib_t '/opt/google-earth/libgooglesearch.so'

At the conclusion of running these commands Google Earth loads in OpenGL format.  However the error sequence should not occur in the first place.

Since this problem has been occurring since last November and across an array of updates to various Linux modules, including SELinux, and every time an update comes out these commands have to be re-run - I contend this is a bug for someone.  I had this bug in Fedora 10 and now in 11.

I'm sure the developers on all sides are pointing fingers at each other.  As a consumer - I just want the problem resolved....
Comment 13 Miroslav Grepl 2009-08-03 10:44:33 EDT
We have the security context for google-earth libraries in the /opt/google-earth directory in F11 selinux-policy.  

You can check the default selinux-policy labeling using matchpathcon

for example:
# matchpathcon /opt/google-earth/libmeasure.so
/opt/google-earth/libmeasure.so	system_u:object_r:textrel_shlib_t:s0


So you can run 'restorecon' for fixing this issue.

# restorecon -R -v /opt/google-earth/
Comment 14 Charles McGowen 2009-08-03 12:03:21 EDT
Miroslav,

First let me say thank you because I know you are in fact trying to help.  However, Please put your end user hat on here for a minute.  Also, please do not take the following words personally - as they in all probability are more directed at Google than you.  Again I know you did in fact help with a band-aide to get my system running.  However, that isn't the issue.  I came to this system to assist in the implementation of a permanent resolution so no one ever had this problem ever again.  I was not looking for a band-aide.

Second, I was under the impression that this system was purposed to gather facts and position strategic resolution for the issue presented.  I thought that the preamble for it (this web site) said something like that.

Third:  The matchpathcon command above resulted in a "segmentation error".
        The restorecon command resolved the problem (I presume) since it
        apparently recursively rippled through the libraries and updated 
        information in the system.

Please understand that the goal in the following language is intended to improve the foundation Linux provides and not to beat anyone up.  So I would please ask that these words not be taken personally.

Check?

Why should I have to check... anything?  The installation program should simply do what its supposed to do - work.  Period.  It doesn't.  Therefore something somewhere is broken.  People all over the place have been beating their heads against a wall on this problem since November of 2008.  That's a lot of head banging.  There's no telling how many got frustrated and simply gave up.

See, I'm just confused.  I thought developers were supposed to have installation programs or policy programs perform matchpathcon and restorecon commands.  I had no idea you expected Joe Schmoe to be cognizant enough to use their x-ray vision glasses to see into the guts of an application like Google-Earth and instantly recognize that where it was placing its libraries wasn't where the operating system thought they should go.  Geeze - I thought programmers made those decisions - not the consuming user.

How in the name of creation is Joe average schmoe supposed to figure out that long line of gobbledy gook in the matchpathcon line above to correct their problem?

I clearly recognize that while this might be a clue (presuming other end users come here and read this) for an end user on where to place their band-aide - it does not address the underlying issue directly so that the "out-of-box experience" for the end user is one of seamless installation that integrates with the operating system to deliver the desired function.  The intent here is to eliminate all those bad experiences people have been suffering since November of 2008......

How do we fix that?    Is this an SELinux problem or a Google problem?

Again - I believe the restorecon command above realigned all the earlier command band-aides issued to temporarily correct the situation.  Should the Google-Earth installation program executed that command prior to its exit?

What are the next steps required in order for this problem to never rear its head for anyone else?

Thank you for your kind response and assistance.
Comment 15 Daniel Walsh 2009-08-04 06:19:49 EDT
Charles.  

Before you attack Fedora, realize the problem is with google-earch having libraries that are built incorrectly.  Secondly google-earch does not use rpm I believe to install their packages.  rpm would/should have labeled the files correctly.  We are just trying to "bandaid" over bugs in another companies products.
Comment 16 Charles McGowen 2009-08-20 09:18:29 EDT
Daniel,

I thought I said that.  If I was not clear.  I LOVE Fedora.  All the folks there are great!  If I said something stupid that gave any other impression then I offer my humble apologies.

Having said that, not only did I point Google Earth staffies to this "bug" (so they would hopefully learn to build their libraries correctly) but I posted the link through which everyone else can do the same.  Squeaky wheel gets the grease....  See Comment #7 above.

Also having said all of this; there is a general and most likely an ethereal expectation, more accurately a "positioning" of the human using the system that I don't agree with.  "Isolation and separation of "root" from "human" such that human only has access to "root" through sudo layering" is an example of what I mean.  However, that is a philosophical discussion and has nothing to do with this.  So let's not run down that rat hole here.  I mention it only so folks might gain a bit larger of view of the perspective I feebly made an attempt to convey. (e.g. That of the end user caught in the cross fire.)

Also please know that my comments ARE IN THE CONTEXT OF having made linkage from this bug over to the Google Earth forums.  Specifically much of my comments above were intended for the eyeballs of the Google Earth programming team which I hope reads this.  Again - I should have been more clear in my comments and again offer my humble apologies in that regard.

For what its worth - I have professional experience in guiding operating system structures, ergonomics, and development.  Those days are long gone and water down stream.  The point is I don't make any of these comments lightly.  I may be old and washed up but I'm not a typical "Duh is this a compooter" user....  FYI & AA....   grains of salt freely available in your local shaker.....  and lest anyone reading this does not understand the reference: http://en.wikipedia.org/wiki/Grain_of_salt

My many thanks to everyone working specifically on Fedora as well as all other incarnations of Linux.  The puppy has grown much over the last 15 years.
Comment 17 Daniel Walsh 2009-09-04 11:44:23 EDT
*** Bug 504718 has been marked as a duplicate of this bug. ***
Comment 18 Robert Townley 2009-10-26 23:17:14 EDT
restorecon -R -v /opt/google-earth/ 

seemed to have fixed it, but i ran a bunch of other commands as well.

i don't suppose there is anyway for the selinux warning to tell users to run
restorecon -R -v /opt/google-earth/ 
instead of sending them through all this, is there.
Again, yes, i realize the problem rests with google developers and documentation, but i was hoping there might be a better way for selinux to convey the fix.


Thank You.
Comment 19 Daniel Walsh 2009-10-27 09:57:38 EDT
Robert Do you have the AVC's that were reported. In F12 this should have told you to run restorecon,   I want to verify that would happen with your AVCs.
Comment 20 Bug Zapper 2009-11-18 04:55:42 EST
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '10'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 10 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Note You need to log in before you can comment on or make changes to this bug.