Problems with GNOME, autofs, NFSv4 and Kerberos security

[infestator]

Hi all,

I've configured a server on Ubuntu 10.04 which serves NFSv4, LDAP, and Kerberos.
Autofs configuration is exposed via LDAP so I can simply configure autofs-ldap to turn on my autofs. Kerberos is for NFSv4 security and network authentication. Together this make a SSO and single home per network user. But I've met the following problems:

1. Ubuntu 10.10 with GNOME UI works unstable when I use network user to authenticate and NFS home. The problems were in the following:
   
   1. on login into GNOME screen the .ICEAuthority problem appears (message "Could not update ICEauthority file /home/<username>/.ICEauthority"). But it does not appear every time I log in, and I could not deteсt any regularity
   2. the Empathy says that it cannot connect to dconf service and this issue prevents it to store any configuration except accounts
   3. Evince does not run at all. It just tells nothing except "Killed" in console (I don't know real message because I use Russian translation, but suppose that it says "Killed")
   
   I understand that Ubuntu 10.10 is unstable now, but I am not sure that these problems are the Ubuntu problems but not GNOME and/or NFSv4/Kerberos misconfiguration.
2. Ubuntu 10.04 which runs on my laptop does not start gssd daemon automatically so I cannot use my NFSv4 shares from server until manually restart gssd (/etc/default/nfs-common file is configured properly, I've checked it few times)

The main problem is Ubuntu 10.10. If it is a bug I will submit it to bug tracker. I've checked manually that my NFS works with all special file types and allows all operations, also I tried to mount with nolock option. Nothing helped.

Please advice what to do. I can perform additional tests if they will provide any information.


--
Thanks,
Alexander

[infestator]

Problem still exists in stable release.
I have noticed that dconf establishes a connection to my NFSv4:

tcp        0      0 192.168.1.10:59879      192.168.1.1:389         ESTABLISHED 18641/dconf-service

Also I had found a bug related to Empathy problem.
Evince also began to say that it cannot connect to dconf, but now it launches.

$ LANG=C evince

(evince:19067): EggSMClient-WARNING **: Failed to connect to the session manager: None of the authentication protocols specified are supported


** (evince:19067): CRITICAL **: Unable to contact dconf service

The problem with .XAuthority remains.

The problem with GSSD was because of GSSD starts before LDAP which was on the same machine. I have solved it placing GSSD daemon start after LDAP.

[esposj]

I'm seeing similar issues on the boxes we upgraded to 10.10

Evince is returning with "killed".
ICEauthority errors from time to time.
Occational Firefox issues (not sure if its related or not yet).

Kerberos / Winbind authenticating over Active Directory NFS provided via drbd cluster for home directories..

My initial plan will be rolling the 10 machines that we upgraded to 10.10 back to 10.04

[valentijnsessink]

on login into GNOME screen the .ICEAuthority problem appears (message "Could not update ICEauthority file /home/<username>/.ICEauthority"). But it does not appear every time I log in, and I could not deteсt any regularity

Hi, the "could not update ICEauthority" message only comes up on first login; or if you lost your kerberos ticket. So logging in with ssh; then logging in with GDM will not show the message, as you have acquired your ticket with the ssh shell session.

I'm not sure why this is; currently looking into it. Did you file a bug already?

[infestator]

Hi all, thanks for replies!

Hi, the "could not update ICEauthority" message only comes up on first login; or if you lost your kerberos ticket. So logging in with ssh; then logging in with GDM will not show the message, as you have acquired your ticket with the ssh shell session.

I'm not sure why this is; currently looking into it. Did you file a bug already?

I am not sure that kerberos ticket is lost at the moment I log in. It should be acuired vice versa, because if it was not so I would not be able to login at all. E.g. if a local user does not have a krb ticket he cannot even "cd" into nfs home dir. But after login I have full access to my NFS home dir. May be the issue is in that the ticket is acquired after .XAuthority file is tried to be written by GDM or GNOME?

I did not submitted any bugs yet. I really don't know if this is misconfiguration issue or a bug. There is already the bug which relates to dconf+NFS issue (my Empathy and Evince problems).

[samjam]

I also have this with ubuntu 10.10, NFS4 and autofs but I don't use kerberos.

I also get this in dmesg every time it happens:
[ 47.451378] non-accessible hardlink creation was attempted by: gnome-session (fsuid 1001)

I just pkill -u $USER and login again and it works.

Very annoying though.

[chimney]

I'm also experiencing this problem while using NFSv4, Ubuntu 10.10, automounter and LDAP for authentication. The error, "Could not update ICEauthority file /home/<username>/.ICEauthority" doesn't appear on the first login (after the workstation has booted), but will appear on the second login using the SAME userid. Any further logins using the same userid appear to produce the error randomly. Has anyone else heard anything about this issue?

Chimney

[samjam]

I think it is a race condition made worse with slow file systems.

It seems that by stracing /usr/lib/gdm/gdm-session-worker (with -fp option) the error always happens. Here is the strace result.

I can't work out why these various system calls are all "unfinished". (I know what it means, but did the calls ever finished? And yet the .ICEauthority-c was eventually made.

Below is strace of a session that failed, grep'd for .ICEauthority

[pid  3624] stat64("/home/anne/.ICEauthority-c",  <unfinished ...>
[pid  3624] creat("/home/anne/.ICEauthority-c", 0666 <unfinished ...>
[pid  3624] link("/home/anne/.ICEauthority-c", "/home/anne/.ICEauthority-l" <unfinished ...>
[pid  3624] open("/home/anne/.ICEauthority", O_RDWR <unfinished ...>
[pid  3624] access("/home/anne/.ICEauthority", F_OK <unfinished ...>
[pid  3624] unlink("/home/anne/.ICEauthority-c" <unfinished ...>
[pid  3624] unlink("/home/anne/.ICEauthority-l" <unfinished ...>

^C was hit on the strace -fp after the error about failing /ICEauthority was shown.

[wapsi]

Hi,

I'm having exactly the same problem. I'm using NFSv4 (/home) and NIS for authentication.

Here is my dmesg:
[16050.814763] nautilus[26957] general protection ip:7f01d8b5a07d sp:7fffa4e77460 error:0 in libgobject-2.0.so.0.2600.0[7f01d8b2b000+49000]
[16073.802079] non-accessible hardlink creation was attempted by: gnome-session (fsuid 1000)

and I'm getting those .ICEauthority errors too. When I login first time the error appears, but it doesn't at the next time I login.

I've noticed that there appears a file .ICEauthority-c too when the error appears. That .ICEauthority-c file is mapped first like this:

-rw-r--r-- 1 4294967294 4294967294 0 2010-12-15 21:51 .ICEauthority-c

after few seconds it will be mapped:

-rw-r--r-- 1 myusername myusername 0 2010-12-15 21:51 .ICEauthority-c

This issue appears only with Ubuntu 10.10. I've same NFS and NIS configs in my Ubuntu 10.04 and I've no troubles like this. Maybe this is bug?

[wapsi]

Okay, for your information: this bug doesn't appear when mounting home directories with OpenAFS (+krb+openldap).

http://www.openafs.org/