kdeinit changes ownership of ~/.ICEauthority if run via (a kde program via) sudo

[Stefan Kluth]

I changed the screen resolution in one session. This worked well, with one
small exception: the background picture was still at the old resolution. After
I logged out I could not login again.
The error message in /xsession-errors was helpful: "Can't open(?) .ICEauthority".

In a aconsole I did

skluth@pcatlas13 ~ $ ls .ICEauthority
-rw------- 1 root root 332 Oct 4 09:27 .ICEauthority

I did "chgrp skluth .ICEauthority; chown .ICEauthority" and the problem was fixed.

Cheers, Stefan

[Matt Zimmerman (mdz)]

The screen resolution configuration program does not run with root privileges,
so it cannot have changed the ownership of this file. It must have been
something else that happened during the same session.

What other programs did you run during that session? Did you make any other
configuration changes? Anything which prompted you for the root password? Did
you use sudo at all?

[Stefan Kluth (skluth)]

Hmmm ... I confirmed that changing the screen resolution up or down and
logout/login works.

Otherwise the session which had the ownership of ~/.ICEAuthority mysteriously
changed
was a lengthy one running several days. I certainly used sudo to get packages.
 There
was a similar report of "can't login" on ubuntu-users recently.

[Stefan Kluth (skluth)]

Ahhhh, k3bsetup is the culprit!

I finally remembered that I also toyed with k3b. It tells me on first startup that
cdrdao and cdrecord should run with higher previleges, please run k3bsetup. When
you do that you are greeted with a window for the root password which doesn't work
of course on ubuntu. So I did

sudo k3bsetup

and let it change permissions, apply changes and exit the program. After that I
found

skluth@pcatlas13 ~ $ ls -lrt .ICEauthority
-rw------- 1 root root 529 Oct 4 10:42 .ICEauthority

and a while later the following error messages:

skluth@pcatlas13 ~ $ Mutex destroy failure: Device or resource busy
skluth@pcatlas13 ~ $ ICE default IO error handler doing an exit(), pid = 24278,
errno = 0
ICE default IO error handler doing an exit(), pid = 24304, errno = 0

[Matt Zimmerman (mdz)]

(bug in unsupported package, closing)

[Daniel Stone (daniels)]

Yes, this is k3b's fault for being so horrendously bad. The only reason it
slips past is that it's typically run from within KDE, thus a .ICEauthority file
is usually created user:user 700, as KDE (mainly DCOP, IIRC) makes massively
extensive use of ICE. An enterprising KDE packager may want to write a wrapper
script for k3bsetup that touches ~/.ICEauthority and then runs sudo k3bsetup.real.

[Stefan Kluth (skluth)]

The easy fix for this problem is to enable the root account before starting
k2b (and thus k3bsetup) for the first time, see the faq.

[Matthew East (mdke)]

I'm reopening this bug, because (a) kde is now supported :) and (b) the number
of users that complain of this problem when running both gnome and kde is
astonishing. To summarise, the problem is that kde is changing the permissions
on the file ~/.ICEauthority

M

[Matt Zimmerman (mdz)]

*** Bug 19236 has been marked as a duplicate of this bug. ***

[Paul O'Malley (ompaul-deactivatedaccount)]

this error can be a show stopper for a new user I managed to activate it two ways
with a ctrl+alt+f1 and reboot
with a ctrl+alt+backspace, followed by a reboot
The ownership of the file is root:root

[Matt Zimmerman (mdz)]

(In reply to comment #9)
> this error can be a show stopper for a new user I managed to activate it two ways
> with a ctrl+alt+f1 and reboot
> with a ctrl+alt+backspace, followed by a reboot
> The ownership of the file is root:root
>

That seems unlikely to me. Did you check the ownership of the file before your
test, and do nothing else during the same session?

[Matt Zimmerman (mdz)]

*** Bug 23903 has been marked as a duplicate of this bug. ***

[TLE (k-nielsen81)]

Don't know If it is k3b (or only k3b) that's the problem. I don't think I ran
the k#b setup that last login before I had the error. And also theres a fellow
in this thread http://www.ubuntuforums.org/showthread.php?t=77555 that says he
had the error and don't have k#b installed. One additional piece of information.
When I logged out the last time before the bug I noticed that the processer was
operating at 100 %, odd because I wasn't running anything. top said it was klogd
that used it. I thought that was wierd that a log deamon should use that much
resources but didn't mind it much. Don't know if it is of any use.

[essexman (ralphsmail)]

(In reply to comment #12)
> Don't know If it is k3b (or only k3b) that's the problem. I don't think I ran
> the k#b setup that last login before I had the error. And also theres a fellow
> in this thread http://www.ubuntuforums.org/showthread.php?t=77555 that says he
> had the error and don't have k#b installed. One additional piece of information.
> When I logged out the last time before the bug I noticed that the processer was
> operating at 100 %, odd because I wasn't running anything. top said it was klogd
> that used it. I thought that was wierd that a log deamon should use that much
> resources but didn't mind it much. Don't know if it is of any use.

This is an old unresolved bug and I had the same problem with 5.04 and now it is
happening with 5.10. I think it may be linked to using a kde app just before
logging out. I just had it occur after using K3B
Search the forums for ICEauthority and I got 107 threads, search for ICE
authority and chown and I get 37 threads.

I think this should be upgraded to Major

[Anderson Lizardo (lizardo)]

Here goes what I've found about this bug:

* The culprit is actually kdeinit, which is run by every kde program (so every
kde program run with "sudo" will trigger this bug). To confirm that, run these
commands as normal user (be sure not to be running any KDE application!):

ls -l ~/.ICEauthority # should have correct permissions
sudo kdeinit # will run kde init daemons
ls -l ~/.ICEauthority # should be owned by "root:root" now
sudo kdeinit_wrapper kdeinit_shutdown # shutdown kdeinit daemons
sudo chown user:user ~/.ICEauthority # fix permissions back

* By default, sudo runs with "always_set_home" flag disabled. This means that
the HOME variable is kept to current user's home and not /root. Run

sudo bash -c 'echo $HOME'

to confirm that. Whether this is expected or not, I don't know.

* kdeinit writes to $HOME/.ICEauthority by default (this can be changed by
setting the ICEAUTHORITY environment variable). Given that HOME is kept as
/home/user when running through sudo, /home/user/.ICEauthority is overwritten
and its ownership/permissions set to root:root.

* How to fix/workaround it - some options:

  1) Add the "always_set_home" flag to "Defaults" in /etc/sudoers. Note that
this will have the effect of setting the HOME variable to /root when sudo'ing to
root. This means that programs that rely upon $HOME and "~/" will have its
behaviour affected (e.g. KDE programs run through sudo will read config from
/root/.kde instead of /home/user/.kde).

  2) Create a wrapper around /usr/bin/kdeinit to set the ICEAUTHORITY variable
to "/root/.ICEauthority" when UID is 0.

  3) Add a session script to remove the old ICEauthority. The command:

echo 'rm -f $HOME/.ICEauthority' > /etc/X11/Xsession.d/99fix-iceauthority

seems to do the trick. I'm not sure whether this approach may have other
side-effects, though.

From these options, (2) seems the less intrusive and fixes exactly the problem
reported (i.e. is not "too generic" as (1) and (3)).

[Suzan (suzan72)]

This old bug is still unfixed?

I agreed, this error occured if a KDE-App is started under GNOME with sudo.
A lot of users have this problem. This is a "KILLER" for all new users!

Pleease fix it for dapper! :-)

[Dennis Kaarsemaker (dennis)]

The wrapper-around-kdeinit approach seems reasonable, is there any reason not to
do this?

[pablovp (pablovp86)]

*** Bug 26222 has been marked as a duplicate of this bug. ***

[Carthik Sharma (carthik)]

Changing status to Confirmed.

Have there been any updates to this old bug?

[Matt Zimmerman (mdz)]

The difference seems to be that libICE is using getenv("HOME") rather than the more reliable getpwuid(getuid()) to find out where the user's home directory is. That's VERY old code, though, and it may not be wise to change its behaviour (definitely not for 6.06).

Another way of looking at the problem is this: why is KDE manipulating the ICEauthority file at all in this case? I don't think GNOME does, though it too uses ICE.

Also interesting, in the Debian bug I just linked, a user reports that they can no longer reproduce on current sid (having had the problem there before). Maybe they've found a workaround?

[Matt Zimmerman (mdz)]

If anyone is curious, it looks like the place where this is happening is dcop/dcopserver_shutdown.c:cleanupDCOPsocket(). It shells out to "iceauth remove" which writes a new .ICEauthority and then renames it in place of the old one.

I suppose another fix would be for iceauth to preserve ownership and permissions when it does this, which seems somewhat less intrusive.

[Matt Zimmerman (mdz)]

Please upgrade to this version and let me know if it fixes the problem for you:

iceauth (1:1.0.1-0ubuntu2) dapper; urgency=low

  * Preserve permissions and ownership on .ICEauthority when replacing it
    (more or less resolves LP#8785)

 -- Matt Zimmerman <email address hidden> Thu, 4 May 2006 19:27:16 -0700

[Matthew East (mdke)]

An Italian user has reported that this problem is *still* present. He runs Dapper, and kppp. I've asked him to subscribe to this bug.

[Matt Zimmerman (mdz)]

Please provide the version of iceauth the user has installed, and provide their name. Otherwise, we have no way to contact them.

Setting to unconfirmed as there isn't enough information to confirm the observed behaviour, nor that this is the same issue.

[Matthew East (mdke)]

The user I mentioned hasn't expressed any interest in chasing the bug up, so I'm going to have to change the status back to Fix released, as before.

[zay2 (alan-kesselmann)]

The same problem keeps popping up in kubuntu's latest version.

ive encountered it with kubuntu 8.04 (kde 3.5.9)
and kubuntu 8.10 (kde 4.1)

Trying to fix screen resolution i ran startx as root from logging in from console mode (not starting kde at splash screen).

After trying to log in as common user from splash screen i got .ICEauthority error again.

[Terence Simpson (tsimpson)]

The real "fix" is to NOT use sudo with GUI/KDE/Gnome aplications, use kdesudo/gksudo, this will set up the correct environment for GUI applications.

[zay2 (alan-kesselmann)]

Hello

But how can i fix this? chown the file for my user and group?

Or log in console not kde and run it as kdesduo startx? That will fix the
ownership also?

Alan Kesselmann

2008/12/7 Terence Simpson <email address hidden>

> The real "fix" is to NOT use sudo with GUI/KDE/Gnome aplications, use
> kdesudo/gksudo, this will set up the correct environment for GUI
> applications.
>
> --
> kdeinit changes ownership of ~/.ICEauthority if run via (a kde program via)
> sudo
> https://bugs.launchpad.net/bugs/8785
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in "kdelibs" source package in Ubuntu: Fix Released
>
> Bug description:
> I changed the screen resolution in one session. This worked well, with one
> small exception: the background picture was still at the old resolution.
> After
> I logged out I could not login again.
> The error message in /xsession-errors was helpful: "Can't open(?)
> .ICEauthority".
>
> In a aconsole I did
>
> skluth@pcatlas13 ~ $ ls .ICEauthority
> -rw------- 1 root root 332 Oct 4 09:27 .ICEauthority
>
> I did "chgrp skluth .ICEauthority; chown .ICEauthority" and the problem was
> fixed.
>
> Cheers, Stefan
>

[Jonathan Thomas (echidnaman)]

I would chown your home directory recursively to be safe.
Then, if you ever need to fix X again, I would recommend that you login in to the console as a normal, use sudo to launch the terminal program to fix xorg.conf, then run startx normally. (Not as sudo, startx doesn't need to be run as root)

[zay2 (alan-kesselmann)]

2008/12/8 Jonathan Thomas <email address hidden>

> I would chown your home directory recursively to be safe.
> Then, if you ever need to fix X again, I would recommend that you login in
> to the console as a normal, use sudo to launch the terminal program to fix
> xorg.conf, then run startx normally. (Not as sudo, startx doesn't need to be
> run as root)

Thanks alot. I ran startx beeing root because i needed to be root to change
the contents of xorg.conf. But thanks. At least now i know the way to fix
this :)

>
>
> --
> kdeinit changes ownership of ~/.ICEauthority if run via (a kde program via)
> sudo
> https://bugs.launchpad.net/bugs/8785
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in "kdelibs" source package in Ubuntu: Fix Released
>
> Bug description:
> I changed the screen resolution in one session. This worked well, with one
> small exception: the background picture was still at the old resolution.
> After
> I logged out I could not login again.
> The error message in /xsession-errors was helpful: "Can't open(?)
> .ICEauthority".
>
> In a aconsole I did
>
> skluth@pcatlas13 ~ $ ls .ICEauthority
> -rw------- 1 root root 332 Oct 4 09:27 .ICEauthority
>
> I did "chgrp skluth .ICEauthority; chown .ICEauthority" and the problem was
> fixed.
>
> Cheers, Stefan
>