Ask Your Question
1

Google Chrome crashes after installation

asked 2015-10-30 20:19:43 -0500

Raven gravatar image

updated 2015-10-31 11:25:24 -0500

I've tried several times to install Google Chrome on my new Fedora 22 desktop. It "installs" but the actual problem is when I try to open it, it shows up on Docky, then there is a fast blip and it closes down. The error in SELinux follows. I literally am BRAND NEW to Linux. My brother suggested Fedora so I downloaded and installed it a few days ago. If there is a way to fix this, will someone please provide step-by-step instructions for dummies? Again, literally know nothing about Linux. Everything I have done has been from searching the Google-verse

SELinux is preventing abrt-hook-ccpp from getattr access on the file file.

*****  Plugin catchall_labels (83.8 confidence) suggests   *******************

If you want to allow abrt-hook-ccpp to have getattr access on the file file
Then you need to change the label on file
Do
# semanage fcontext -a -t FILE_TYPE 'file'
where FILE_TYPE is one of the following: NetworkManager_log_t, (snip list) zebra_tmp_t, zoneminder_log_t. 
Then execute: 
restorecon -v 'file'


*****  Plugin catchall (17.1 confidence) suggests   **************************

If you believe that abrt-hook-ccpp should be allowed getattr access on the file file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep abrt-hook-ccpp /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

Additional Information:
Source Context                system_u:system_r:abrt_dump_oops_t:s0
Target Context                system_u:object_r:unlabeled_t:s0
Target Objects                file [ file ]
Source                        abrt-hook-ccpp
Source Path                   abrt-hook-ccpp
Port                          <Unknown>
Host                          new-host-2.home
Source RPM Packages           
Target RPM Packages           
Policy RPM                    selinux-policy-3.13.1-128.18.fc22.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     new-host-2.home
Platform                      Linux new-host-2.home 4.2.3-200.fc22.x86_64 #1 SMP
                              Thu Oct 8 03:23:55 UTC 2015 x86_64 x86_64
Alert Count                   10
First Seen                    2015-10-29 19:19:47 CDT
Last Seen                     2015-10-30 20:10:38 CDT
Local ID                      2b528f89-a02e-474d-938d-4ac8ae67a095

Raw Audit Messages
type=AVC msg=audit(1446253838.930:1186): avc:  denied  { getattr } for  pid=5413 comm="abrt-hook-ccpp" path="ipc:[4026531839]" dev="nsfs" ino=4026531839 scontext=system_u:system_r:abrt_dump_oops_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=file permissive=0


Hash: abrt-hook-ccpp,abrt_dump_oops_t,unlabeled_t,file,getattr
edit retag flag offensive close merge delete

3 Answers

Sort by ยป oldest newest most voted
1

answered 2015-10-31 09:28:07 -0500

D4zzY gravatar image

run in your termainal

sudo dnf  install --nogpgcheck https://dl.google.com/linux/direct/google-chrome-stable_current_$(uname -m).rpm
edit flag offensive delete link more
0

answered 2015-10-30 21:24:33 -0500

aeperezt gravatar image

I have install Google-Chrome from google Repo for Fedora with no issue. Only choose proper one http://www.google.com/chrome/index.ht...

edit flag offensive delete link more
0

answered 2015-10-31 11:25:07 -0500

This error is a bit misleading if you don't know the things involved. The complaint is that abrt attempted to access a file that it not allowed to. To understand this, it will help to know what ABRT is, and a bit about SELinux mechanism that polices it and other system services.

abrt is the Automatic Bug Reporting Tool. When an application on a system running ABRT crashes, it will automatically gather information relevant to the crash. Information that is known to be sanitized of any personal information can typically be submitted without user intervention; information that could potentially contain PII is make available for review and cannot be submitted without an account.

On your system, google-chrome crashed, and ABRT attempted to do it's job, but that failed. The ABRT error is an effect of the crash, not the cause. There are some clues in the error report anyway, so read on:

A security feature called SELinux is running on your computer. It knows about labels for files, classifications for background services called context, and rules about what contexts are allowed to access each label. This ensures that compromised services can't get to any files they aren't supposed to. For example, instead of uploading known sanitized content, a hypothetical compromised abrt service could upload personal files from your home directory to an unknown place. ( No, I don't think that's happened to you, just an example :)

The most common cause of issues relating to SELinux are improperly labeled files. In your post, we see this:

Raw Audit Messages
type=AVC msg=audit(1446253838.930:1186): avc:  denied  { getattr } for  pid=5413 comm="abrt-hook-ccpp" path="ipc:[4026531839]" dev="nsfs" ino=4026531839 scontext=system_u:system_r:abrt_dump_oops_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=file permissive=0

Let's break it down:

type=AVC msg=audit(1446253838.930:1186):

It's an avc type message, which will be on most or all SELinux denials. It has a msg number. Nothing exiting yet.

avc:  denied  { getattr } for  pid=5413 comm="abrt-hook-ccpp"

SELinux denied getattr, or get attribute, privileges to a process with the process id of 5413 and a name of abrt-hook-cpp. Now we know the name; the process ID isn't too important unless you want to check on it in real time.

path="ipc:[4026531839]" dev="nsfs" ino=4026531839

This is what the process was denied access to. I'm not exactly sure what resource this might be indicating, but it's not too important right now.

scontext=system_u:system_r:abrt_dump_oops_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=file permissive=0

Here's the meat of the complaint. scontext is the process, tcontext is the file. The file was unlabeled! There was no rule saying that abrt was allowed to access it, so it was refused. Unlabeled files usually only happensfor one of two reasons: You are using a filesystem that does not support SELinux labels, like NTFS, for system directories; or, you have disabled SELinux, written ... (more)

edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

Stats

Asked: 2015-10-30 20:19:43 -0500

Seen: 377 times

Last updated: Oct 31 '15