Cannot login: could not update ICEauthority file .ICEauthority

Bug #823775 reported by marcobra (Marco Braida) on 2011-08-10
This bug affects 24 people
Affects Status Importance Assigned to Milestone
ecryptfs-utils (Ubuntu)
lightdm (Ubuntu)
Michael Terry

Bug Description

This at login this morning (Ubuntu fully updated/upgrade using terminal) also creating a new user, rebooting and trying to login with it confirm me this issue, i'm report this with apport-bug using terminal and then accessing to the pc using ssh to complete details...

in dmesg:

[ 49.309253] type=1400 audit(1312961869.108:19): apparmor="DENIED" operation="mknod" parent=1284 profile="/usr/share/gdm/guest-session/Xsession" name="/home/ubuntu/.ICEauthority-c" pid=1352 comm="gnome-session" requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000

Description: Ubuntu oneiric (development branch)
Release: 11.10

 apt-cache policy x11-xserver-utils
  Installato: 7.6+2
  Candidato: 7.6+2
  Tabella versione:
 *** 7.6+2 0
        500 oneiric/main i386 Packages
        100 /var/lib/dpkg/status

ls -l .ICEauthority
-rw------- 1 ubuntu ubuntu 24058 2011-08-10 09:42 .ICEauthority

uid=1000(ubuntu) gid=1000(ubuntu) gruppi=1000(ubuntu),4(adm),20(dialout),24(cdrom),46(plugdev),112(lpadmin),120(admin),122(sambashare)

ProblemType: Bug
DistroRelease: Ubuntu 11.10
Package: x11-xserver-utils 7.6+2
ProcVersionSignature: Ubuntu 3.0.0-8.10-generic 3.0.1
Uname: Linux 3.0.0-8-generic i686
Architecture: i386
 udevd[275]: error: runtime directory '/run/udev' not writable, for now falling back to '/dev/.udev'

 fsck from util-linux 2.19.1
 /dev/sdb1: clean, 282274/1068960 files, 1660349/4271616 blocks
CompizPlugins: [core,composite,opengl,cube,rotate,kdecompat,unityshell]
Date: Wed Aug 10 10:13:57 2011
DistUpgraded: Log time: 2011-06-07 21:25:25.400061
DistroCodename: oneiric
DistroVariant: ubuntu
 ATI Technologies Inc Radeon RV100 QY [Radeon 7000/VE] [1002:5159] (prog-if 00 [VGA controller])
   Subsystem: PC Partner Limited RV100 QY [Sapphire Radeon VE 7000] [174b:7112]



 Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
 Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
 Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
 Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
MachineType: MSI MS-6593
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.0.0-8-generic root=UUID=9129c272-f8be-4616-93c3-9a021ae8c2db ro quiet splash vt.handoff=7
SourcePackage: x11-xserver-utils
UpgradeStatus: Upgraded to oneiric on 2011-06-07 (63 days ago) 04/02/01
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: 07.00T MS-6593
dmi.board.vendor: MSI
dmi.board.version: 1.0
dmi.chassis.asset.tag: 0123ABC
dmi.chassis.type: 3
dmi.chassis.vendor: Uknown Chassis Manufacture
dmi.chassis.version: Version 1.00
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr07.00T:bd04/02/01:svnMSI:pnMS-6593:pvr1.0:rvnMSI:rnMS-6593:rvr1.0:cvnUknownChassisManufacture:ct3:cvrVersion1.00: MS-6593
dmi.product.version: 1.0
dmi.sys.vendor: MSI
version.compiz: compiz 1:
version.libdrm2: libdrm2 2.4.26-1ubuntu1
version.libgl1-mesa-dri: libgl1-mesa-dri 7.11-0ubuntu2
version.libgl1-mesa-dri-experimental: libgl1-mesa-dri-experimental N/A
version.libgl1-mesa-glx: libgl1-mesa-glx 7.11-0ubuntu2
version.xserver-xorg: xserver-xorg 1:7.6+7ubuntu6
version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.6.0-1ubuntu13
version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:6.14.2-1ubuntu2
version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.15.901-1ubuntu2
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:0.0.16+git20110411+8378443-1

Related branches

description: updated
description: updated
description: updated
description: updated
description: updated

From terminal

sudo apt-get --puge --reinstall install gdm


From terminal

sudo apt-get --purge --reinstall install gdm


Timo Aaltonen (tjaalton) wrote :

something weird going on with lightdm then.

affects: x11-xserver-utils (Ubuntu) → lightdm (Ubuntu)
Changed in lightdm (Ubuntu):
assignee: nobody → Michael Terry (mterry)
Sebastien Bacher (seb128) wrote :

Thank you for your bug

Michael, could you have a look? I think it's something wrong in the update, I had to manually clean the .ICEauthority as well today there was a stalled on from yesterday which was breaking login (could access to the display due to it)

Changed in lightdm (Ubuntu):
status: New → Confirmed
Smot (smot-msn) wrote :

Just updated to 11.10 online today from a fresh 11.04. Was unable to log in - message "Cannot update ICEAuthority" was displayed.

I tried the "purge" suggestion (Marco, above) but this made no difference.

Will try again in a couple of weeks....

Michael Terry (mterry) wrote :

I have been unable to reproduce the .ICEauthority aspect of this bug. But I have been able to diagnose another problem with logging in that might be some user's actual problem: bug 824123.

John Aylward (t3h2) wrote :

Solution above worked for me. Thanks

Michael Terry (mterry) wrote :

I haven't gotten the .iCEauthority message in a bit, but I think I have been able to hit the same bug, just without the popup. I'm suspecting it's related to ecryptfs.

 * It seems to be easier to reproduce after rebooting via Ctrl+Alt+Del
 * If after hitting this, I log into a VT, the problem goes away
 * If after hitting this, I log into a VT as a different user, I can see a recent .Xauthority file and .xsession-errors in /home/mike all by itself (this is the near-empty mount point over which ecryptfs gets put)

Sebastien Bacher (seb128) wrote :

not sure if we are hijacking this bug wrongly but Barry opened bug #824594 about .Xauthority

Martin Pitt (pitti) wrote :

As I also can't login through lightdm right now, I tried to follow this recipe as well. Merely removing .ICEauthority and .Xauthority doesn't seem to be sufficient for me; may it be that this is just a red herring, and that logging into the VT is a required step here to unlock ecryptfs?

What I did notice is that lightdm defaults to the wrong user for me (my "joe" test user), and already starts a PAM session for joe right at startup:

[+20.82s] DEBUG: Greeter start authentication for joe
[+20.82s] DEBUG: pam_start("lightdm", "joe") -> (0x7f8a440248f0, 0)

Changing to "martin" and trying to log in fails, I just get a black screen quickly, and then returns to lightdm. It does work if I switch between some more users, and then back to "martin". I need to examine this more closely, might very well be totally unrelated to this bug.

Changed in lightdm (Ubuntu):
importance: Undecided → High
Dustin Kirkland  (kirkland) wrote :

Adding ecryptfs-utils as "affected". I don't *think* the bug is there, as it seems to work with gdm, but having this bug show up under ecryptfs-utils should help with its discoverability.

Changed in ecryptfs-utils (Ubuntu):
status: New → Confirmed
importance: Undecided → High
Dustin Kirkland  (kirkland) wrote :

At a quick glance, it looks to me like lightdm is trying to do something in the user's home directory before pam_ecryptfs finishes mounting it.

Dustin Kirkland  (kirkland) wrote :

The strange thing to me is that before the encrypted home is mounted, $HOME is perm'd 500. So not even the owner should be able to write to it. This is by design to prevent you from accidentally writing cleartext data to your home.

Even though that's the case, the failed lightdm login process creates two files in the unmounted, read-only home:
 1) .dmrc
 2) .Xauthority

This seems to me like lightdm is doing some funny business as root, and then chowning this files back over to the user?

Dustin Kirkland  (kirkland) wrote :

Okay, digging through the lightdm code a little, I'm looking at:

in src/display.c, the start_user_session() function does:
    g_debug ("Starting user session");
    user = pam_session_get_user (authentication);
    /* Load the users login settings (~/.dmrc) */
    dmrc_file = dmrc_load (user_get_name (user));

And in src/dmrc.c, the dmrc_load() function:
    /* Load from the user directory, if this fails (e.g. the user directory
     * is not yet mounted) then load from the cache */
    path = g_build_filename (user_get_home_directory (user), ".dmrc", NULL);
    have_dmrc = g_key_file_load_from_file (dmrc_file, path, G_KEY_FILE_KEEP_COMMENTS, NULL);
    g_free (path);

Basically, if the user's home directory is not mounted, then something is *wrong*, and we shouldn't be proceeding yet. Lightdm should be blocking until the pam session start completes successfully.

Further down, this is just wrong:
    /* Update the users .dmrc */
    if (user)
        path = g_build_filename (user_get_home_directory (user), ".dmrc", NULL);
        g_file_set_contents (path, data, length, NULL);
        if (getuid () == 0 && chown (path, user_get_uid (user), user_get_gid (user)) < 0)
            g_warning ("Error setting ownership on %s: %s", path, strerror (errno));
        g_free (path);

This is creating the ~/.dmrc file in a read-only $HOME directory as the root user, and then chowning it over to $USER. This leaves un-encrypted files in the user's home directory, which is very much undesirable, if a user is encrypting their home.

I haven't found a solution yet as I'm only looking at this a little bit while at a conference, but I thought I'd leave a few notes here :-)

Martin Pitt (pitti) wrote :

My "starts pam session for other user early" apparently was a red herring. While that looks odd, according to the log it does complete the PAM session for "martin" successfully. So I confirm that I have the exact same bug here: I need to log into VT1 to unlock my ecryptfs home dir. I still need more than one try after that in lightdm, but that might be a followup race condition, and I'll debug it after fixing this initial issue.

Changed in lightdm (Ubuntu):
status: Confirmed → Triaged
Michael Terry (mterry) wrote :

We do wait to start the session until PAM authorizes us. But it's true that lightdm apparently likes to reach into the user's home directory before PAM authorizes us.

I tested by forcing lightdm to treat "/tmp" as the user's home directory and this problem went away. So what I think is happening is that lightdm opens a file in /home/user and that prevents the ecryptfs mount from happening...

Changed in lightdm (Ubuntu):
status: Triaged → Fix Committed
Changed in ecryptfs-utils (Ubuntu):
status: Confirmed → Fix Committed
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package lightdm - 0.9.3-0ubuntu4

lightdm (0.9.3-0ubuntu4) oneiric; urgency=low

  * Updated to current trunk, that's a candidate version version for the next
    update, it fixes those issues:
    - login doesn't work for ecryptfs users (lp: #823775, #824594)
    - "lightdm-gtk-greeter segfaults in get_user_iter when adding a new user"
    (lp: #822470)
    - fix fallback from org.freedesktop.Accounts to passwd format (lp: #817835)
    - empty autologin-user should not be passed to pam (lp: #817581)
  * debian/
    - build-depends on quilt, it's needed with source v1
    - don't build-depends on valac, vala is not used in the current version
  * debian/lightdm.install:
    - install the manpages as well
  * debian/lightdm.manpages:
    - dropped, it's installed by the upstream make install
  * debian/rules:
    - use the quilt rule
  * debian/source/format:
    - use source v1, it works better with vcs workflows
 -- Sebastien Bacher <email address hidden> Thu, 18 Aug 2011 15:29:42 +0200

Changed in lightdm (Ubuntu):
status: Fix Committed → Fix Released

Hmm, was there a regression here? I have lightdm 0.9.7-0ubuntu1, and see the exact the same issue with "could not update ICEauthority file .ICEauthority". User has the home directory crypted with ecryptfs, which stays unencrypted, which is why the error is shown.

Michael Terry (mterry) wrote :

Tomasz, do you have autologin turned on or "login without a password"? Those are incompatible with ecryptfs and I just uploaded a new gnome-control-center that will prevent you from using such options with it.

EricDHH (ericdhh) wrote :

Was okay since yesterdays updates to the system. I got the "could not update ice-authority" even when the user was login'ed at another VT before. Autologin is not activated here, no encrypted user can login to the gui but on VT to their home.

naxHo (aborilov-gmail) wrote :

Tonight I upgraded from 11.04 to 11.10, and now I can't login under my user, but can login in VT, and can login in lightDM to guest session.
I have autologin turned on 11.04

naxHo (aborilov-gmail) wrote :

I have the home directory crypted with ecryptfs too

Michael Terry (mterry) wrote :

naxHO, you shouldn't have both autologin and ecryptfs enabled. You'll have to turn off autologin.

naxHo (aborilov-gmail) wrote :

And how can I do this now?

Michael Terry (mterry) wrote :

Try editing /etc/lightdm/lightdm.conf and removing the autologin-user line.

naxHo (aborilov-gmail) wrote :

there no such line in config

Michael Terry (mterry) wrote :

Robert, do you know why someone would be autologging in without that being set in /etc/lightdm/lightdm.conf?

naxHo (aborilov-gmail) wrote :

no! I have autologin in GDM in ubuntu 11.04.
Now I can't login in lightDM under user with crypted home directory

naxHo (aborilov-gmail) wrote :

I've delete file .Xauthority from home directory and now can login

naxHo (aborilov-gmail) wrote :

Have the same thing on the work laptop. After delete .Xauthority I can login

ray (arkibott) wrote :

Well, made the mistake to go for precise.
So nothing works at all. System hangs. Kernel Panic. Other bugs..

Well, had that issue also. Deleting, changing the Attributes of that .Xauthority file did not fix a thing.

My workaround: Purge gdm. Not lightdm. Remove the leftover files manually.. ( in /etc/ and /var/lib/gdm? ) Purge and reinstall itself wasn't enough. Then reinstall via aptitude. Works again then.

ray (arkibott) wrote :

Downside of this. Now i have to start Xorg manually. Start lightdm or gdm manually. How can i restore it to be started automatically?

ray (arkibott) wrote :

The issue got marked as a duplicate somewhere else so i joined this bug. But actually i don't have ecryptfs and the workaround comment #9 suggested was not anywhere near possible or a remedy. This was more likely a upgrade permission messup somewhere within gdm / lightdm.

tags: added: oneiric2precise precise
Tyler Hicks (tyhicks) wrote :

I believe that this bug has been solved long ago with a lightdm upload. Marking the ecryptfs-utils task as fix released as this issue seems to be fixed.

Changed in ecryptfs-utils (Ubuntu):
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers