Description of problem: changing context of .Xauthority from unconfined_u:object_r:xauth_home_t:s0 to system_u:object_r:xdm_home_t:s0 after user logon cause problems for remore login by "slogin -X username@hostname" or starting vncserver for user username Version-Release number of selected component (if applicable): selinux-policy-targeted-3.6.32-89.fc12.noarch kdm-4.3.5-2.fc12.i686 kde-settings-kdm-4.3-17.noarch tigervnc-1.0.0-3.fc12.i686 libselinux-utils-2.0.90-3.fc12.i686 selinux-policy-3.6.32-89.fc12.noarch tigervnc-server-module-1.0.0-3.fc12.i686 tigervnc-server-1.0.0-3.fc12.i686 libselinux-python-2.0.90-3.fc12.i686 libselinux-2.0.90-3.fc12.i686 openssh-server-5.2p1-31.fc12.i686 How reproducible: 100% Steps to Reproduce: 1. use kdm as display manager 2. create account username 3. login as username by kdm 4. logout 5. try to login as "username" by "slogin -X ..." from different PC Actual results: Last login: Thu Feb 18 23:06:49 2010 from homedesk /usr/bin/xauth: /home/username/.Xauthority not writable, changes will be ignored $ xclock X11 connection rejected because of wrong authentication. Error: Can't open display: localhost:10.0 Expected results: user can use slogin with X11 forwarding vncserver for user can start OK. Additional info: After user logout (kdm), selinux context of .Xauthority is system_u:object_r:xdm_home_t:s0 --- user can login with enabled X11 forwarding and vncserver for user can start correct, if context of .Xauthority is unconfined_u:object_r:xauth_home_t:s0
This is because the same process is creating both files. Gdm creates its xauthority files in /var/run/gdm echo $XAUTHORITY /var/run/gdm/auth-for-dwalsh-gHE0bI/database And .xsession_errors in the homedir. kdm should do something similar. Or fix the context when it creates the file. Running restorecon on the .Xauthority file will fix the label. Does your session run restorecond? ps -eZ | grep restorecond staff_u:staff_r:staff_t:s0-s0:c0.c1023 2209 ? 00:00:00 restorecond This should also make sure the labeling is correct in the homedir.
Thank you for taking the time to report this issue to us. This is an issue which is best addressed by the upstream developers. Please file a report at bugs.kde.org , and when done add the upstream report info to this report. We will continue to track the issue in the centralized upstream bug tracker, and will review any bug fixes that become available for consideration in future updates. Thank you for the bug report. Steven M. Parrish KDE & Packagekit Triager Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
This is our problem I think... Lemme dig up some details.
Yeah, the fix was intrusive, see bug #524583 , so we could apply only for F-13+ *** This bug has been marked as a duplicate of bug 524583 ***