Bug 113153 - .Xauthority deleted from NFS mounted home
Summary: .Xauthority deleted from NFS mounted home
Keywords:
Status: CLOSED CANTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: gdm
Version: 3
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Ray Strode [halfline]
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-01-08 22:51 UTC by Kasper Dupont
Modified: 2007-11-30 22:10 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2006-10-29 21:10:05 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Kasper Dupont 2004-01-08 22:51:53 UTC
Description of problem:
If home directory is NFS mounted .Xauthority is deleted on login.

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

How reproducible:
Happens always

Steps to Reproduce:
1. Log in on a computer that access home directory over NFS
  
Actual results:
.Xauthority is deleted

Expected results:
Cookie for current session is written to .Xauthority, cookies for
different displays are preserved.

Additional info:
This will cause problems for other X sessions run by the same user on
different computers. The problem is probably related to the
root-squash feature by default enabled on NFS exports. Updating of
.Xauthority needs to be done with ID of the user loging in, not as
root. Testing done with the failsafe sessions to avoid multiple
desktop environment sessions from corrupting configuration files.
After failing to update .Xauthority gdm will fallback to creation of a
.Xauthority in /tmp. This happens after damage has happened, and the
fallback does not work for remote applications.

Comment 1 Ray Strode [halfline] 2005-05-11 22:14:22 UTC
Fedora Core 1 is now maintained by the Fedora Legacy project for
security updates only. If this problem is a security issue, please
reopen and reassign to the Fedora Legacy product. If it is not a
security issue and hasn't been resolved in the current FC3 updates or
in the FC4 test release, reopen and change the version to match.

Comment 2 Kasper Dupont 2005-05-12 05:39:01 UTC
I have also seen this problem in FC3. However not all installations of FC3 are
affected, so far I have been unable to identify the difference between those
installations.

Comment 3 Kasper Dupont 2005-05-21 17:17:59 UTC
I think this bug might be the same as 171188 on gnome bugzilla:
http://bugzilla.gnome.org/show_bug.cgi?id=171188

Comment 4 Kasper Dupont 2005-08-24 11:11:38 UTC
I think the bug depends on the permissions on your home directory. Apparently if
the mode is 700 .Xauthority is erroneously removed, if the mode is 755 it is not
removed.

Comment 5 Mogens Kjaer 2005-08-24 11:36:51 UTC
I "fixed" this problem by using the KDM displaymanager:

echo 'DISPLAYMANAGER="KDE"' >>/etc/sysconfig/desktop

and changing

AllowRootLogin=false to true

in /etc/X11/xdm/kdmrc, if you want to log in as root.

Note: You'll still run GNOME when you log in, it's just the
login window that has changed.

Comment 6 Matthew Miller 2006-07-10 22:09:32 UTC
Fedora Core 3 is now maintained by the Fedora Legacy project for security
updates only. If this problem is a security issue, please reopen and
reassign to the Fedora Legacy product. If it is not a security issue and
hasn't been resolved in the current FC5 updates or in the FC6 test
release, reopen and change the version to match.

Thank you!


Comment 7 John Thacker 2006-10-29 21:10:05 UTC
Closing per previous comment and lack of response.  FC3 and FC4 are supported
for security fixes only by Fedora Legacy.  If this is a security bug, please
reopen.  Please retest against FC5 or FC6 and set the version appropriately if
the bug still occurs in one of those still supported versions of Fedora Core. 
Thanks!

Comment 8 Ray Strode [halfline] 2006-10-30 00:06:36 UTC
We ended up changing GDM to use a system specific Xauthority file for FC6.


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