Created attachment 525058 [details] /var/log/messages Description of problem: When logging in after applying updates from testing, I got the "Oh no!" screen repeatedly. Further investigation revealed the cause: Sep 27 09:29:45 worm kernel: [ 1160.747610] type=1400 audit(1317112185.695:19): avc: denied { read } for pid=1155 comm="dbus-daemon" path="/home/twaugh/.loca l/share/icc/edid-f2817a6f9cd36a70be9c67ce322007eb.icc" dev=dm-5 ino=24687 sconte xt=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_ r:data_home_t:s0 tclass=file [...] Sep 27 09:29:47 worm kernel: [ 1162.252121] type=1400 audit(1317112187.200:20): avc: denied { read } for pid=1155 comm="dbus-daemon" path="/home/twaugh/.loca l/share/icc/edid-f2817a6f9cd36a70be9c67ce322007eb.icc" dev=dm-5 ino=24687 sconte xt=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_ r:data_home_t:s0 tclass=file [...] Sep 27 09:29:47 worm gnome-session[6272]: WARNING: App 'gnome-settings-daemon.desktop' respawning too quickly Version-Release number of selected component (if applicable): gnome-settings-daemon-3.1.92-1.fc16.x86_64 How reproducible: 100% Steps to Reproduce: 1.Set up an ICC profile for the monitor in F-15 2.Upgrade to F-16 plus updates-testing Actual results: Fails to log in. Expected results: Should be resilient against this failure. Additional info: Here are the packages I'd upgraded: tar-1.26-2.fc16 ibus-rawcode-1.3.1.20100707-5.fc16 yum-3.4.3-5.fc16 nautilus-sendto-3.0.1-1.fc16 ypbind-1.33-7.fc16 pm-utils-1.4.1-12.fc16 gsettings-desktop-schemas-3.2.0-1.fc16 totem-mozplugin-3.2.0-1.fc16 libreport-plugin-kerneloops-2.0.5.982-1.fc16 libreport-newt-2.0.5.982-1.fc16 libreport-plugin-logger-2.0.5.982-1.fc16 libreport-plugin-bugzilla-2.0.5.982-1.fc16 libreport-gtk-2.0.5.982-1.fc16 totem-nautilus-3.2.0-1.fc16 gnome-bluetooth-3.2.0-1.fc16 totem-3.2.0-1.fc16 gnome-bluetooth-libs-3.2.0-1.fc16 libreport-python-2.0.5.982-1.fc16 libreport-2.0.5.982-1.fc16 perl-Git-1.7.6.4-1.fc16 git-1.7.6.4-1.fc16 Also attached: /var/log/messages from logging in. Using restorecon on the ~/.local/share/icc subdirectory fixed the problem.
The login error was caused by the AVC which should have been fixed by SELinux updates. The g-s-d failures here are apparently not critical and reported elsewhere.
So, this is essentially https://bugzilla.redhat.com/show_bug.cgi?id=738803 back from the grave. I don't know if this is how Tim hit it, but I've found one reproducible way you can still hit this problem, with the help of Jonas Thiem: Install F15 Install gnome-color-manager Somehow cause an ICC profile to be imported for your user - import a file or calibrate the monitor Upgrade to F16 boom! The icc_data_home_t context does not exist in F15, F15 just creates the profiles with a normal 'user home directory' context. When you upgrade to F16 the context is not fixed, and so you hit the same 'g-s-d blows up if the context on an ICC profile is wrong' bug that we had trouble with during Beta. This probably isn't release critical, as gnome-color-manager wasn't default in F15, so hopefully only people who read hughsie's blog will get bitten by it. But it is pretty nasty. Proposing as NTH. g-s-d should just be more robust and not crash when this happens.
Discussed at 2011-10-28 NTH review meeting, accepted as NTH per reasoning in comment #2.
Adam are you still seeing this?
dwalsh: there's a scenario in which it can be reproduced described in comment #2, I tested that myself. unless you've changed something since then? it doesn't happen in the straightforward 'install f16 and try to boot' case any more, which is what blocked beta, but by installing f15, creating a profile, then upgrading to f16, you can still wind up with a mislabelled profile.
But does this stop you from logging in? One quick fix would be to add ~/.local/share/icc to restorecond_users.
"But does this stop you from logging in?" yes. g-s-d has not been fixed yet to not crash when it sees a mislabelled profile. "One quick fix would be to add ~/.local/share/icc to restorecond_users." only if restorecond is installed, right?
I'm seeing this bug. It doesn't prevent login, but after login, this prevents anything other than logging out. $ ls -lZ ~/.local/share/icc -rw-rw-r--. amit amit unconfined_u:object_r:data_home_t:s0 edid-aedae9cc758035a92e98b5122d91dfec.icc I also have the following in my kernel log: [ 150.092297] type=1400 audit(1319992063.856:7): avc: denied { read } for pid=746 comm="dbus-daemon" path="/home/amit/.local/share/icc/edid-aedae9cc758035a92e98b5122d91dfec.icc" dev=sda6 ino=136474269 scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:data_home_t:s0 tclass=file [ 150.093254] type=1400 audit(1319992063.857:8): avc: denied { read } for pid=1214 comm="colord" path="/home/amit/.local/share/icc/edid-aedae9cc758035a92e98b5122d91dfec.icc" dev=sda6 ino=136474269 scontext=system_u:system_r:colord_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:data_home_t:s0 tclass=file [ 150.129243] type=1400 audit(1319992063.893:9): avc: denied { getattr } for pid=1210 comm="colord" path="/home/amit/.local/share/icc/edid-aedae9cc758035a92e98b5122d91dfec.icc" dev=sda6 ino=136474269 scontext=system_u:system_r:colord_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:data_home_t:s0 tclass=file Reproduction steps seem similar to comment 2. I don't think I installed gnome-color-manager separately; I think it came as default with the F15 install.
"I don't think I installed gnome-color-manager separately; I think it came as default with the F15 install." At least on the DVD, it doesn't. I checked. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
policycoreutils-2.1.4-7.fc16 will have the fix for restorecond_users.conf
should definitely document this as it wasn't fixed in the release. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
I just came the upgrade path F15->F16 using the yum method to upgrade. I got bitten by the same issue. Removing .local/share/icc remedies. I never installed gnome-color-manager separately. In fact I have never created an ICC profile on my own. It looks like it was installed automatically. After removing the folder above, and successfully logging in, the profile for my semi-professional NEC monitor is back.
policycoreutils-2.1.4-7.fc16 hasn't been pushed as an update yet, but it can be found on http://koji.fedoraproject.org/koji/buildinfo?buildID=271629 . It would be nice to get positive feedback from someone who really had the problem and got it fixed by this update.
Hello Mads, I restored my previous .local/share/icc folder. The shell crashes on login, as expected. Then I installed all policycoreutils packages from that build page $ yum list policycoreutils* Geladene Plugins: auto-update-debuginfo, langpacks, presto, refresh-packagekit Installierte Pakete policycoreutils.x86_64 2.1.4-7.fc16 installed policycoreutils-gui.x86_64 2.1.4-7.fc16 installed policycoreutils-newrole.x86_64 2.1.4-7.fc16 installed policycoreutils-python.x86_64 2.1.4-7.fc16 installed policycoreutils-restorecond.x86_64 2.1.4-7.fc16 installed policycoreutils-sandbox.x86_64 2.1.4-7.fc16 installed Verfügbare Pakete policycoreutils-debuginfo.x86_64 2.1.4-3.fc16 fedora-debuginfo I rebooted to be safe, but still could not login. I reverted back to my other .local/share/icc folder and am able to log in now. -> I believe this has not been fixed. Attaching the .xsession-errors log as well as the last bits from syslog.
Created attachment 532148 [details] xsession error log
Created attachment 532149 [details] last lines of syslog
Please disregard that last syslog Nov 7 23:41:22 rivendell kernel: [ 1874.109569] type=1400 audit(1320705682.984:7): avc: denied { read } for pid=949 comm="dbus-daemon" path="/home/nazgul/.local/share/icc/edid-94c6e9825a66d7b9a7e4b11982d49754.icc" dev=sda7 ino=398693 scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file Nov 7 23:41:24 rivendell kernel: [ 1875.420653] type=1400 audit(1320705684.294:8): avc: denied { read } for pid=949 comm="dbus-daemon" path="/home/nazgul/.local/share/icc/edid-94c6e9825a66d7b9a7e4b11982d49754.icc" dev=sda7 ino=398693 scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file
-- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
I got substantially the same problem (the "Oh no!" screen repeatedly) before logging in (few seconds after the "submarine" background appears), with the following message logged continuously into the /var/log/messages file: Nov 9 13:17:05 ulisse kernel: [ 788.463179] type=1400 audit(1320841025.886:401 ): avc: denied { read } for pid=2645 comm="gnome-settings-" name="share" dev= sdb1 ino=7307737 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system _u:object_r:default_t:s0 tclass=dir I upgraded a x86_64 version from F15 to F16 by the preupgrade method (a machine where F15 had already been installed in a similar way as upgrade from F14). After the first post-install reboot, X server crashed because NVidia drivers had obviously to be reinstalled. At the subsequent reboot after reinstalling NVidia drivers, the aforementioned error occurred. I also tried to remove .local/share/icc but, as expected from the occurrence of the error BEFORE the login menu appeared, nothing changed
If you have default_t labels then either your homedir is badly mislabeled restorecon -R -v /home If you have moved your homedir to another directory then you need to setup labeling for your homedir.
I haven't moved any homedir, nor the restorecon command changes anything in the problem/error. I also created an additional brand new user, but the "Oh no!" screen still appears BEFORE the "log in" window gets displayed (the "submarine" splash screen stay on for 2-4 seconds, a couple of black, quickly flashing stripes showing meantime), so I can't imagine how the problem may depend upon the configuration of a single user (what if more than one user exist?). In addition to my previous comment, I also noticed that, within a long series of messages similar to that reported in my previous comment, also two different messages (those containing "GsmDBusClient") occurred: Nov 9 17:35:23 ulisse kernel: [13792.347378] type=1400 audit(1320856523.322:67): avc: denied { read } for pid=2954 comm="gnome-settings-" name="share" dev=sdb1 ino=7307737 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:default_t:s0 tclass=dir Nov 9 17:35:23 ulisse gnome-session[2944]: DEBUG(+): GsmDBusClient: obj_path=/org/gnome/SessionManager interface=org.gnome.SessionManager method=IsInhibited Nov 9 17:35:23 ulisse gnome-session[2944]: DEBUG(+): GsmDBusClient: obj_path=/org/gnome/SessionManager interface=org.gnome.SessionManager method=IsInhibited Nov 9 17:35:27 ulisse dbus-daemon[2840]: ** Message: No devices in use, exit Nov 9 17:35:27 ulisse kernel: [13796.336193] type=1400 audit(1320856527.322:68): avc: denied { read } for pid=2954 comm="gnome-settings-" name="share" dev=sdb1 ino=7307737 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:default_t:s0 tclass=dir
What does matchpathcon /home/USERNAME Say? What is the output of ls -lZ /
matchpathcon /home/USERNAME: /home/piero unconfined_u:object_r:user_home_dir_t:s0 and the same result is obtained for the new user just created (i.e. after the upgrade): /home/sw unconfined_u:object_r:user_home_dir_t:s0 ls -lZ / : dr-xr-xr-x. root root system_u:object_r:bin_t:s0 bin dr-xr-xr-x. root root system_u:object_r:boot_t:s0 boot drwxr-xr-x. root root system_u:object_r:cgroup_t:s0 cgroup drwxr-xr-x. root root system_u:object_r:etc_runtime_t:s0 data01 drwxr-xr-x. root root system_u:object_r:device_t:s0 dev drwxr-xr-x. root root system_u:object_r:etc_t:s0 etc drwxr-xr-x. root root system_u:object_r:home_root_t:s0 home drwxrwx---+ root users system_u:object_r:nfs_t:s0 iomega dr-xr-xr-x. root root system_u:object_r:lib_t:s0 lib dr-xr-xr-x. root root system_u:object_r:lib_t:s0 lib64 drwx------. root root system_u:object_r:lost_found_t:s0 lost+found drwxr-xr-x. root root system_u:object_r:mnt_t:s0 media drwxr-xr-x. root root system_u:object_r:nfs_t:s0 merlin drwxr-xr-x. root root system_u:object_r:mnt_t:s0 mnt lrwxrwxrwx. root root system_u:object_r:usr_t:s0 opt -> /data01/opt dr-xr-xr-x. root root system_u:object_r:proc_t:s0 proc dr-xr-x---. root root system_u:object_r:admin_home_t:s0 root drwxr-xr-x. root root system_u:object_r:var_run_t:s0 run dr-xr-xr-x. root root system_u:object_r:bin_t:s0 sbin drwxr-xr-x. root root system_u:object_r:var_t:s0 srv drwxr-xr-x. root root system_u:object_r:sysfs_t:s0 sys drwxrwxrwt. root root system_u:object_r:tmp_t:s0 tmp drwxr-xr-x. root root unconfined_u:object_r:default_t:s0 tyner drwxr-xr-x. root root system_u:object_r:usr_t:s0 usr drwxr-xr-x. root root system_u:object_r:var_t:s0 var
Whats this? drwxr-xr-x. root root unconfined_u:object_r:default_t:s0 tyner ls -lZ /home/piero/.local/share/icc matchpatcon /home/piero/.local/share/icc
drwxr-xr-x. root root unconfined_u:object_r:default_t:s0 tyner this is a directory used to mount via NFS a remote filesystem /home/piero/.local/share/icc doesn't exist any more (it was and empty dir)
*** Bug 752544 has been marked as a duplicate of this bug. ***
Pietro something is very wrong on you machine. Could you execute yum reinstall selinux-policy-targeted And see if anything breaks. default_t should only be in directories policy does not know about. And policy should know about the /home directory.
Actually, it's quite possible that something is wrong on my machine, the origin of the problem probably going back to F14, because after installing that release, I was unable to export via NFS the filesystems of this machine to any other computer on its subnet. The origin of that problem was never understood, also because of poor diagnostic messages (the mount command only issued a connection timeout). This problem, although only given a fast try without any real attempt to track it, was still observed after both F14->F15 and F15->F16 upgrades. Back to the F16 login problem, after switching from gdm to kdm, the login windows appears and works flawlessly. I issued the "yum reinstall selinux-policy-targeted" command, but, apparently nothing changed (in particular, gdm doesn't work, kdm works).
Please attach /etc/selinux/targeted/contexts/files/file_contexts.homedirs
pietro, dan: the issue pietro is encountering seems to be rather different from the one this report is intended for. before things become any more confusing, could you please split discussion of pietro's bug off into a new report? thanks. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Ok Pietro, can you open a different bugzilla.
I got this again when upgrading my main machine to f16. It is true that the context of /home/*/.local/share/icc is (by f16 definition) wrong. It is unconfined_u:object_r:data_home_t:s0 but should be unconfined_u:object_r:icc_data_home_t:s0 in f16. One consequence of that is that "gnome shell" "crashes". That is of course not ok - it should at least have failed gracefully. Since this issue still is assigned to gnome-settings-daemon I assume that this is what really is tracked on this issue. It is however very limited what it can do to solve the problem when SELinux prevents it from accessing its data. I understand that SELinux can't relabel user homes on updates as a general solution ... but perhaps a %post restorecon of /home/*/.local/share/icc could be used as a workaround for most cases anyway? As far as I can see the only real solution to this issue is to accept that the introduction of icc_data_home_t (and other home contexts) in f16 can't be enforced and that the policy still has to allow access to data_home_t.
Miroslav lets back port a1ce0c62f73fb88c07f157624894e7091d1623fc To allow this for F16.
Just reporting that when I ran the 'restorecon' invocation listed for this problem on the common bugs page, it didn't do anything. I had to move the icc directory somewhere else and only then was the login crash fixed.
Adam, did you run the command as root or as the user who had the problem?
I tried as both and in neither case did restorecon seem to make any changes.
(In reply to comment #13) > policycoreutils-2.1.4-7.fc16 hasn't been pushed as an update yet, but it can be > found on http://koji.fedoraproject.org/koji/buildinfo?buildID=271629 . > > It would be nice to get positive feedback from someone who really had the > problem and got it fixed by this update. I just updated yesterday and preupgrade installed policycoreutils-2.1.4-12.fc16.x86_64. I experienced the problem anyway. The chcon command documented at http://fedoraproject.org/wiki/Common_F16_bugs#color-profile-gnome *did* resolve the problem.
Could you run matchpathcon on the path?
Re-proposing as F17 Alpha NTH, as I don't think this has been fixed so could still affect F15 -> F17 upgrades. And it still affects F16 too, of course. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
We are now allowing colord to read the mislabeled file. So I don't think this will be a problem going from F15-F17.
ah, so this is only still open because of chris beland's result? -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
un-proposing, as this has likely already been addressed. will re-propose as blocker/nth if it turns out to still be a problem in testing.
just upgraded from F15 to F16 via preupgrade had updated before upgrade gnome was crashing at logon after upgrade I desinstalled gnome alternate tab extension -> no change I tried the chcon stuff (su -c 'chcon -R -t icc_data_home_t ~/.local/share/icc') errors, says that /root/.local/share/icc doesn't exist (which is true, I never logged as root in X) I've got coreutils-2.1.4.13-fc16 then restorecon -R -v /home/user -> works, I can now logon with this user so I think selinux knew about the fix but it was somehow never applied. This pb is on a netbook, no nfs or special thing I can think of.
"errors, says that /root/.local/share/icc doesn't exist (which is true, I never logged as root in X)" you run the chcon command as user, not root. ~ is a special character, as far as shells are concerned, meaning 'the current user's home directory'. so if you run the command as root, it will try and operate on root's home directory - which is /root - not your regular user's home directory. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Thanks for the explanation. Following http://fedoraproject.org/wiki/Common_F16_bugs#Starting_GNOME_Shell_fails_after_upgrade_from_Fedora_15_with_color_profile_installed, it was not clear if the command had to be run as a user, if it applies to all user or has to be repeated for every user... If I understand well your answer, this command has to be applied for every user but it need the su trick to be able to gain root rights and need to be logged as the user before so the ~ resolve as the home of the current logged in user. I'm not a selinux specialist but it looks like restorecon -R -v /home is easier to apply if it doesn't risk breaking anything else.
Yes the restorecon -R -v /home is fine. Also make sure you yum update to the latest packages.
This solution doesn't work if the home directories are NFS mounted. My configuration is NIS/NFS and I got this after a clean install of Fedora 16 x86_64 onto a new client. The NIS/NFS server is currently still at Fedora 14 (yes, I know, it needs to be upgraded). I've already done a setsebool -P use_nfs_home_dir=1 and even touched .autorelabel on all local file systems followed by a reboot (yes, the relabel was probably not necessary, but I was trying everything). The only solution for logging in right now is to setenforce 0 on a console after the host boots. I also found that if I delete .xsession-errors, the client is unable to recreate it, so there was nothing there at all. However, after logging in with permissive mode, I get this from setroubleshoot for the problem with .xsession-errors Raw Audit Messages type=AVC msg=audit(1337657352.314:256): avc: denied { create } for pid=9468 comm="gdm-session-wor" name=".xsession-errors" scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:user_home_t:s0 tclass=file and this for the problem with the color profile Raw Audit Messages type=AVC msg=audit(1337657354.800:259): avc: denied { read } for pid=1172 comm="dbus-daemon" path="/home/roland/.local/share/icc/edid-866e6d50be308dd540ed7eabf31d3d7a.icc" dev="0:27" ino=12060085 scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:user_home_t:s0 tclass=file I can't quite figure out why it wants to create that color profile; deleting the entire ~/.local tree doesn't help, it gets recreated with that icc file on the next log in.
I should add two things. First, I have another F16 client where logging in was working just fine...until after I added this new client. I'm not quite sure what the old settings were on these files that have caused a problem but the other F16 client is no longer able to log in with the same issue. Second, the NFS home directories are mounted with an explicit context $ ypcat auto.home -rw,rsize=32768,wsize=32768,softintr,bg,tcp,posix,context="system_u:object_r:user_home_t:s0" archos.rlent.pnet:/data/home/&
The "it used to work" is only partly true. I had an Ubuntu client that seems to have done something "interesting" to my settings. After I dumped the Ubuntu client, I trashed all my settings and started over, but somewhere in the process, ~/.config/dconf/user acquired some setting that will in fact work with enforcing turned on, but the g-s-d can't change the background. If I trash the ~/.config/dconf/user (and ~/.cache/dconf/user), then I can't log in without switching to permissive mode. I can bundle the half-working ~/.config/dconf/user file if its of use.
Roland are you saying you have a homedir that is shared with a client, then when you log into the client via NFS and create the content the client works fine. But if you go to the server and attempt to login to the same homedir the login fails because the file is mislabeled?
Sorry, I've said so many different things, I've muddied the description. I was unable to log into the client without donig "setenforce 0". But to further muddy things, it's working now. I logged into the console on the NFS server and ran restorecon on the home directories, then logged in there as my regular user account on the GUI after making sure that I had setenforce 1. That worked without any problem. I delete the troublesome ~/.local/share/icc directory and .xsession-errors just to start over clean and logged out and in again. No problem on the server. So then I tried again on the client. It works now(!). I'm puzzled. Because the mount command is forcing the context, I would not have expected that restorecon on the server would have any effect. I can't think of how logging out and back in on the server X display would reset anyting that would effect selinux. I can confirm that the *directory* ~/.local/share/icc gets created, but not the icc file now. I'm happy it's working, but not sure what went wrong or how to recreate the original problem now.
No idea why this would happen on the client, since the client would have seen the file as labelled nfs_t, while the server would see it with the correct label.
Actually, the client sees it at user_home_t because of the context specified in the NIS map (see comment #48 above). But both dbus-daemon and colord choked on it. The behavior that has changed is tat the icc file is NOT being created any more when I log in. That's curious and I don't know why. But it would appear that simply because the file doesn't exist, both dbus-daemon and colord are "happy". I saved the old config files, so I've tried copying the icc file back into ~/.local/share/icc but the login failure does NOT reoccur. I do get an error about dbus-daemon which prevents my desktop background from being set. === from /var/log/messages, now when login works === SELinux is preventing /bin/dbus-daemon from read access on the file /home/roland/.local/share/icc/edid-4621142970fb6768d5db9c1e6f23f332.icc. === from /var/log/audit/audit.log, now when login works === type=AVC msg=audit(1337874438.888:10250): avc: denied { read } for pid=1204 comm="dbus-daemon" path="/home/roland/.local/share/icc/edid-4621142970fb6768d5db9c1e6f23f332.icc" dev="0:27" ino=12060276 scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:user_home_t:s0 tclass=file == from /var/log/audit/audit.log, previously, when login failed === type=AVC msg=audit(1337660935.332:2201): avc: denied { read } for pid=1204 comm="dbus-daemon" path="/home/roland/.local/share/icc/edid-866e6d50be308dd540ed7eabf31d3d7a.icc" dev="0:27" ino=11684643 scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:user_home_t:s0 tclass=file type=AVC msg=audit(1337660935.333:2202): avc: denied { read } for pid=1714 comm="colord" path="/home/roland/.local/share/icc/edid-866e6d50be308dd540ed7eabf31d3d7a.icc" dev="0:27" ino=11684643 scontext=system_u:system_r:colord_t:s0 tcontext=system_u:object_r:user_home_t:s0 tclass=file I think someone else already mentioned that login actually did work, but the the only thing I could do is either click the logout button or by using ALT-F1, I could get to view sealerts. So I think the only reason I can get in now is because the file is not being created. I'm not sure which config was controlling that.
Well in F17 we are allowing this access.
Good, I was about to post that after a reboot of the client today, the dbus-daemon error has come back (as has the file). I suspect the on-again, off-again nature of the problem for me has to do with another NIS/NFS client that is still running F14, but I'm too lazy to track it down without a good reason. The F16 host where I've currently had to turn off enforcing is an internal host, so while not ideal, it's not so bad having it off.
This message is a reminder that Fedora 16 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 16. 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 '16'. 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 16'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 16 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, you are encouraged to click on "Clone This Bug" and open it against that version of Fedora. 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
Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.