Bugzilla – Bug 177480
Root change the owner of .ICEauthority of an user
Last modified: 2008-08-25 18:20:37 UTC
I work in gnome as ordinary user. I open terminal run su and then I install fonts using kcontrol. Afterr this my (user) file .ICEauthority has ownes set to root.
kcontrol is acting like k3b in another bug. gdm resets the .ICEauthority file to the proper permissions if you log in again. See bug 164520 and bug 162952.
JPR: so you're saying that gdm resets the permissions of $HOME/.ICEauthority to root:root even if $HOME not the one from root?
No, I'm saying gdm resets the permissions back to those of the user so the user can access the file in their session again. The .ICEAuthority getting set to root:root has in the past been caused by running 'sudo k3b', see bug 119295. We fixed gdm to work around this, but the underlying cause still seems to be there.
I also work in GNOME as a user. When I open konqueror "Super user mode", the .ICEAuthority getting set to root:root. After that, I get DCOPserver errors everytimg I launch KDE applications like Kate, etc. Then when I reboot, login fails. So I have to login as root and change .ICEAuthority's permissions to login as user.
Mr. Marumoto, are you using KDM or GDM, and if GDM, is it the very latest version available from updates? Because GDM should fix the permission problem on its own when logging in, so you don't get locked out by this KDE bug.
I'm very sorry but I'm not sure... (I'm kind of new to Linux..) I searched "KDM" software installation in YaST, and KDM was not found(unchecked), but GDM is installed. So I guess I'm using GDM. The version is gdm-2.8.0.7-57. The strange thing is that I don't get locked out all the time. (DCOPserver error happens all the time though) I have 2 PC running openSuSE 10.1. One is fresh install and the other is upgrade. In the fresh installed PC, I got locked out only a few times. And I just made sure it uses GDM. However, the other was upgrade from 9.x, 10.0 and previously used KDE as a main desktop environment. I'm not sure it uses KDM or not because I'm at home now. This one locks me out all most everytime after I use KDE application as root. I'll check if this PC uses KDM or not tomorrow. thanks Details of "DCOP communications error (KDE System Guard)" ----------------------------------------------------------------- There was a error setting up inter-process communications for KDE. Could not read nework connection list. /home/user/.DCOPserver_SEVERNAME__0 Please check that the "dcopserver" program is running! ----------------------------------------------------------------- in the terminal... #dcopserver /home/user/.ICEauthority not writable, changes will be ignored DCOPClient::attachInternal. Attach failed Authentication Rejected, reason : None of the authentication failed ICE Connection rejected! iceauth : timeout in locking authority file /home/user/.ICEauthority
Thanks a lot! Here's the info I need: - Are you definitely using GDM? - What's the permissions and owner of ~/.Xauthority before logging out and back in? - The same, after logging out and back in? - What happens if you remove .Xauthority and log out and back in? - If you trigger the bug after doing this, what happens?
I meant .ICEauthority, not .Xauthority.
Confirmed, I'm using gnome and GDM for the fresh install of SuSE 10.1. .ICEauthority permissions: 600 owner: MyAccout:users Once I launch Konqueror "Super User mode", permissions: 600 owner: root:root (even if I close Konqueror) I logging out and back in, .ICEauthority permissions: 600 owner: MyAccout:users I did not get locked out. I remove .ICEauthority and logging back in. permissions: 600 owner: MyAccout:users Nothing happens. working great. But I remember that I had to login as root to fix the .ICEauthority's permisson at least once in this PC... >- If you trigger the bug after doing this, what happens? Do you mean like a launching Konqueror "Super User mode"? Same thing happens as I describe in the previous comment. I get DCOPserver errors and occasionally some KDE app crash. I haven't to have a chance to look at the other PC yet. I've gotta feeling that the other one uses KDM because the login screen looks different. And this one locks me out 10 times out of 10. I'll take a look and make sure in a couple of hours.
OK, I'm at the other PC. This one uses KDM. I guess this is because previouslly KDE was the desktop environment... Now everything is the same except that login fails every single time if I use Konqueror Suer User Mode and log out and try to log back in. Now, do you need more information? If not, I'd very much like to change KDM to GDM ;-) thanks
No, that's as much as I needed. It shows that GDM is doing its job working around the bug. The bug itself could be fixed, though, but that's for the KDE team.
Excuse me for bringing this issue again, but today I got locked out again even though I"m using GDM. Here is some info when GDM did not seem to work around the bug. On a fresh install of SuSE 10.1 (Gnome with GDM), I launched nautilus as a root. In a console, % su password % nautilus Using nautilus, I mistakenly open a root owned file with Kate and tried to save it. Of cource, I got error saying I can't save the document. (I was also opening SCIM's (imput method thingy) setup dialog at the same time.) Then, all of a sudden title bar of all the window dissapeared. This happend a couple times and I think this is a XGL related issue but I don't care much. Anyway, I tried to log out and log back in. Opps, I can't log in. So, I logged in as root and checked the .ICEauthority' permisstions. It was me:users, but I reallized that there are .ICEauthority-c and .ICEauthority-l existed. Their permisions are me:users 640. I deleted .ICEauthority-c and .ICEauthority-l and logged out and logged back in succesfully. Hope this helps.
*** Bug 192707 has been marked as a duplicate of this bug. ***
do you have $ICEAUTHORITY set as an environment variable normally? this is the only way that I could find that would make libICE use the wrong file for storing the authentication information.
I have exactly same problem with .ICEauthority. Also when I log out from Gnome, whole SUSE hangs on black screen instead of GDM. I can't even restart X - keyboard is not responding. I have to manually shut down computer - hardware button. The only solution is deleting of all .authority files like .Xauthority, .ICEauthority, .DCOPserver in user home folder and also in root folder. But it is only temporary solution, that usually works for one or two GNOME sessions.
*** Bug 217475 has been marked as a duplicate of this bug. ***
The iceauth tool modifies ~/.ICEauthority by creating a new file and replacing ~/.ICEauthority with this file -> its owned by the user running iceauth. GNOME, gnome-session specifically, sets ICEAUTHORITY to point to the user's .ICEauthority file, and this setting remains after su to root -> there you go.
*** Bug 259678 has been marked as a duplicate of this bug. ***
So is this a KDE bug or a GNOME bug?
I think GNOME should not set ICEAUTHORITY.
*** Bug 262401 has been marked as a duplicate of this bug. ***
I have a fully up to date openSUSE 10.2/GNOME desktop, and this bug just bit me when I ran KPPP as root. Logging out and logging back in via GDM did *NOT* fix the bug. Logging in on a console tty and removing the .ICEauthority* files did fix it. Note also that I was motivated to run KPPP as root precisely because KPPP fails to prompt for the root PW to gain permissions needed to control PPP connections.
GNOME has to set ICEAUTHORITY, or session management won't work for applications that are run as root, meaning your desktop will hang on logout.
Sorry I didn't mean to change this bug.
This was more or less fixed in gnome-session in http://bugzilla.gnome.org/show_bug.cgi?id=89988#c5 - it will now warn you if .ICEauthority is not writable by the user. We already ship that version of gnome-session in 10.3, so I'll mark this bug as fixed.
*** Bug 195132 has been marked as a duplicate of this bug. ***