Hide Forgot
SELinux is preventing /usr/lib64/chromium-browser/chromium-browser from getattr access on the file /home/brian/.config/chromium/Dictionaries/en-US-2-1.bdic. ***** Plugin restorecon (82.4 confidence) suggests ************************* If you want to fix the label. /home/brian/.config/chromium/Dictionaries/en-US-2-1.bdic default label should be config_home_t. Then you can run restorecon. Do # /sbin/restorecon -v /home/brian/.config/chromium/Dictionaries/en-US-2-1.bdic ***** Plugin file (7.05 confidence) suggests ******************************* If you think this is caused by a badly mislabeled machine. Then you need to fully relabel. Do touch /.autorelabel; reboot ***** Plugin file (7.05 confidence) suggests ******************************* If you think this is caused by a badly mislabeled machine. Then you need to fully relabel. Do touch /.autorelabel; reboot ***** Plugin catchall_labels (4.59 confidence) suggests ******************** If you want to allow chromium-browser to have getattr access on the en-US-2-1.bdic file Then you need to change the label on /home/brian/.config/chromium/Dictionaries/en-US-2-1.bdic Do # semanage fcontext -a -t FILE_TYPE '/home/brian/.config/chromium/Dictionaries/en-US-2-1.bdic' where FILE_TYPE is one of the following: rpm_tmp_t, xdm_tmp_t, user_home_type, ld_so_cache_t, chrome_sandbox_tmp_t, sysadm_usertype, unconfined_usertype, gnome_home_type, xdm_var_run_t, net_conf_t, chrome_sandbox_t, staff_execmem_t, user_execmem_t, sysctl_kernel_t, abrt_var_run_t, user_cron_spool_t, execmem_exec_t, admin_home_t, unconfined_execmem_t, sysctl_crypto_t, user_usertype, cgroup_t, chrome_sandbox_exec_t, staff_usertype, abrt_t, bin_t, cert_t, lib_t, logfile, usr_t, abrt_helper_exec_t, xguest_usertype, locale_t, user_tmp_t, etc_t, fonts_t, ld_so_t, user_fonts_t, proc_t, user_tmpfs_t, sysfs_t, config_home_t, fonts_cache_t, user_fonts_cache_t, chrome_sandbox_tmpfs_t, textrel_shlib_t, user_fonts_config_t, xserver_tmpfs_t, iceauth_home_t, xauth_home_t, rpm_script_tmp_t, user_home_t, sosreport_tmp_t. Then execute: restorecon -v '/home/brian/.config/chromium/Dictionaries/en-US-2-1.bdic' ***** Plugin catchall (1.31 confidence) suggests *************************** If you believe that chromium-browser should be allowed getattr access on the en-US-2-1.bdic 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 chromium-browse /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context unconfined_u:unconfined_r:chrome_sandbox_t:s0-s0:c 0.c1023 Target Context unconfined_u:object_r:file_t:s0 Target Objects /home/brian/.config/chromium/Dictionaries/en- US-2-1.bdic [ file ] Source chromium-browse Source Path /usr/lib64/chromium-browser/chromium-browser Port <Unknown> Host brian-laptop Source RPM Packages chromium-12.0.718.0-1.fc15 Target RPM Packages Policy RPM selinux-policy-3.9.16-24.fc15 Selinux Enabled True Policy Type targeted Enforcing Mode Permissive Host Name brian-laptop Platform Linux brian-laptop 2.6.38.6-27.fc15.x86_64 #1 SMP Sun May 15 17:23:28 UTC 2011 x86_64 x86_64 Alert Count 2 First Seen Thu 26 May 2011 12:24:43 PM EDT Last Seen Thu 26 May 2011 12:58:57 PM EDT Local ID 45e499c4-d145-4880-986a-0a5133a4dfc2 Raw Audit Messages type=AVC msg=audit(1306429137.266:634): avc: denied { getattr } for pid=16589 comm="chromium-browse" path="/home/brian/.config/chromium/Dictionaries/en-US-2-1.bdic" dev=dm-3 ino=408777 scontext=unconfined_u:unconfined_r:chrome_sandbox_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:file_t:s0 tclass=file type=SYSCALL msg=audit(1306429137.266:634): arch=x86_64 syscall=fstat success=yes exit=0 a0=17 a1=7fff1ff14110 a2=7fff1ff14110 a3=7fff1ff13f70 items=0 ppid=1 pid=16589 auid=1001 uid=1001 gid=1001 euid=1001 suid=1001 fsuid=1001 egid=1001 sgid=1001 fsgid=1001 tty=(none) ses=6 comm=chromium-browse exe=/usr/lib64/chromium-browser/chromium-browser subj=unconfined_u:unconfined_r:chrome_sandbox_t:s0-s0:c0.c1023 key=(null) Hash: chromium-browse,chrome_sandbox_t,file_t,file,getattr audit2allow #============= chrome_sandbox_t ============== allow chrome_sandbox_t file_t:file getattr; audit2allow -R #============= chrome_sandbox_t ============== allow chrome_sandbox_t file_t:file getattr;
Ditto for read on the same file.
Migrating to Fedora from a distribution that does not support SELinux, and using your existing partition mounted on home? (sudo) restorecon -R -v -F /home If you are sharing this partition between various distributions of which some do not support SElinux then i would suggest you restore contexts of /home each time you boot into Fedora (script maybe?).
(In reply to comment #2) > Migrating to Fedora from a distribution that does not support SELinux, and > using your existing partition mounted on home? Ahhh. Yes, quite. Ubuntu is where I am coming from. > (sudo) restorecon -R -v -F /home Wow. With a ~ that has lots of source trees in it, that takes a bit to process. > If you are sharing this partition between various distributions of which some > do not support SElinux then i would suggest you restore contexts of /home each > time you boot into Fedora (script maybe?). Yeah, gotcha. Is there a test one could do to determine if one came from such a situation? Will some attribute of a commonly/always used file (i.e. ~/.bash_profile perhaps) change when it's been used in another non-selinux distro? Is it just newly created files (in the other distro) which have problems or all files, or all files that are accessed (even for just read)? Thanx much!
Well i determined all this by just identifying that your files were labelled type file_t if you basically do "ls -alZ ~ | grep file_t", and it returns something, then you can be pretty sure that you need to restore contexts. By the way: does ps eZ | grep restorecon return anything? We ave this utility running in your login session that is watching (or at least it should) your home directory and if some file is mislabelled it automatically restores its context. (restorecond -u (gnome-session-properties)
(In reply to comment #4) > Well i determined all this by just identifying that your files were labelled > type file_t > > if you basically do "ls -alZ ~ | grep file_t", and it returns something, then > you can be pretty sure that you need to restore contexts. OK. Cool. So exactly what activity in another non-selinux linux will reset the label to file_t? Just booting to the other linux, or reading a file, or writing it or only newly created files? Just trying to understand a bit better. > By the way: does ps eZ | grep restorecon return anything? nothing other than the grep itself. > We ave this utility running in your login session that is watching (or at least > it should) your home directory and if some file is mislabelled it automatically > restores its context. (restorecond -u (gnome-session-properties) That doesn't seem to be running here.
As soon as you boot into a system that does not support SELinux you will need to relabel (if the partition is mounted there needless to say). You really need restorecond -u especially with google-chrome. I will have to let the big guys comment on that issue, because i do not know the cause of this "bug" and the optimal workaround and/or solution. You may (or may not) be able to configure it manually by installing policycoreutils-restorecond and configuring gnome-session-properties to run "restorecond -u" in your session and then re-login.
Any file created while not in an SELinux kernel will get created without the extended attributes/label. When you do boot with a selinux kernel the unlabeled file will be treated as file_t meaning all confined apps will not be able to access the file. yum install policycoreutils-restorecond Should install the app. The app has a desktop file that I believe kde should start on login. But that would only fix top level directories. not any file created in ~/.config A hack would be to add a restorecon -R ~/.config to your login shell. Which would at least fix the problem you are having.