Description of problem: When running a KDE app (fe kedit or kwrite) sudo from a gnome-terminal in a gnome session (not in KDE) .ICEauthority of the user gets chown-ed root. This prevents later xsessions for this user because .ICEauthority cannot be read. This seems to have to do something with mutexes. Note that in the following expample the output "Mutex destroy failure" happens right after the ls has been issued. The ownership of .ICEauthority is changed right after this error. Version-Release number of selected component (if applicable): gnome-terminal-2.2.1-4 How reproducible (example plus output): [leonard@athlon leonard]$ ls -al .ICE* -rw------- 1 leonard leonard 159 Aug 1 02:55 .ICEauthority -rw------- 1 root root 159 Jul 31 00:55 .ICEauthority.000 [leonard@athlon leonard]$ sudo kedit & [1] 6937 [leonard@athlon leonard]$ kbuildsycoca running... ls -al .ICE* -rw------- 1 root root 348 Aug 1 02:55 .ICEauthority -rw------- 1 root root 159 Jul 31 00:55 .ICEauthority.000 [leonard@athlon leonard]$ sudo kill -TERM 6937 [1]+ Terminated sudo kedit [leonard@athlon leonard]$ ls -al .ICE* -rw------- 1 root root 348 Aug 1 02:55 .ICEauthority -rw------- 1 root root 159 Jul 31 00:55 .ICEauthority.000 [leonard@athlon leonard]$ sudo chown leonard.leonard .ICEauthority [leonard@athlon leonard]$ ls -al .ICE*Mutex destroy failure: Device or resource busy -rw------- 1 leonard leonard 348 Aug 1 02:55 .ICEauthority -rw------- 1 root root 159 Jul 31 00:55 .ICEauthority.000 [leonard@athlon leonard]$ ls -al .ICE* -rw------- 1 root root 159 Aug 1 02:56 .ICEauthority -rw------- 1 root root 159 Jul 31 00:55 .ICEauthority.000 Expected results: .ICEautorithy still owned by user
A guess is that the kde dcop server starts up as root when it's not already running as the user, and the dcop server sets up .ICEauthority. If you start up a KDE app as the user first, then wait a bit and start one up as root, does this still happen?
Indeed, .ICEauthority doesn't get chowned root if any(?) K-app is started by the user first. The behaviour reappears as soon as all K-apps are terminated and root starts a new one. [leonard@athlon leonard]$ kwrite & [1] 4260 [leonard@athlon leonard]$ ls -al .ICEauthority -rw------- 1 leonard leonard 666 Aug 1 05:08 .ICEauthority [leonard@athlon leonard]$ sudo kedit & [2] 4262 [leonard@athlon leonard]$ ls -al .ICEauthority -rw------- 1 leonard leonard 666 Aug 1 05:08 .ICEauthority [leonard@athlon leonard]$ ls -al .ICEauthority -rw------- 1 leonard leonard 666 Aug 1 05:08 .ICEauthority [leonard@athlon leonard]$ ls -al .ICEauthority -rw------- 1 leonard leonard 666 Aug 1 05:08 .ICEauthority [1]- Done kwrite [2]+ Done sudo kedit [leonard@athlon leonard]$ sudo kedit & [1] 4266 [leonard@athlon leonard]$ Mutex destroy failure: Device or resource busy sudo kedit &ICE default IO error handler doing an exit(), pid = 4266, errno = 0 ls -al .ICEauthority -rw------- 1 leonard leonard 477 Aug 1 05:09 .ICEauthority [1]+ Exit 1 sudo kedit [leonard@athlon leonard]$ ls -al .ICEauthority -rw------- 1 leonard leonard 477 Aug 1 05:09 .ICEauthority [leonard@athlon leonard]$ sudo kedit & [1] 4273 [leonard@athlon leonard]$ kbuildsycoca running... ls -al .ICEauthority -rw------- 1 root root 666 Aug 1 05:12 .ICEauthority
Thanks for testing that out. If my theory is correct then the kde daemon needs to take some extra steps to avoid chown'ing the auth cookie file in the process of adding a cookie to it. Changing component.
i confirm this problem here
This bug is reported against old release of Red Hat Linux or Fedora Core that is no longer supported. Chances are that it has been already fixed in newer Fedora Core release. If you still experience the problem with current release of Fedora Core, please update the Version field (you may need to switch Product to Fedora Core first) in the bug report and put it back to NEW state.
Red Hat Linux is no longer supported by Red Hat, Inc. If you are still running Red Hat Linux, you are strongly advised to upgrade to a current Fedora Core release or Red Hat Enterprise Linux or comparable. Some information on which option may be right for you is available at http://www.redhat.com/rhel/migrate/redhatlinux/. Red Hat apologizes that these issues have not been resolved yet. We do want to make sure that no important bugs slip through the cracks. Please check if this issue is still present in a current Fedora Core release. If so, please change the product and version to match, and check the box indicating that the requested information has been provided. Note that any bug still open against Red Hat Linux by the end of 2006 will be closed as 'CANTFIX'. Thanks again for your help.
Issue still is reproducable on FC4. Please test this on FC5 yourself. Shouldn't be too hard to perform a "sudo kedit" and check the ownership of .ICEauthority.
Reading through the report now, i actually don't think this is a bug. Since sudo changes uid of the process (in your case to 0) and keeps $HOME set to what it was previously, then, KDE has no way to find out that the $HOME is not actual supposed home directory of the user in question (root). And you don't want root's .ICEauthority to be owned by someone else, do you? You can use sudo -H to get around that problem. Also note that other files get chowned to root, not only .ICEauthority, so even if the .ICEauthority behaviour changed, the system will still probably break if you run KDE apps with sudo. At best, this could be a feature request to make KDE (and the underlying X libs i assume) play nice with sudo.