I did some more testing, so I run a new kdc (heimdal again) on the
fbsd server (just to eliminate one candidate from my problematic-boxes);
this one is from the fbsd base system (the previous one was from ports),
and the version is 1.1.0. I init'd my realm, and changed the
/etc/krb.conf files on server and client to reflect my new kerberos
implementation.
When I tried to mount the remote share using sec=krb5, gssd segfaulted
again; I was on the exact place as before. Then I started deleting
encryption types from the keytab (using kadmin and del_enctype) to see
if this would help, until only one encryption type was left
(des3-cbc-sha1), but gssd segfaulted repeatedly. Two funny things that I
noticed:
1) when I del_enctype'd des3-cbc-sha1 and tried to kinit -t keytab -k
host/linclient on the linuxbox I got the error:
[root@linuxclient ]# kinit -t keytab -k host/linclient
kinit: krb5_get_init_creds: Looping 11 times while getting initial
credentials
[root@linuxclient ]#
and on the server tail /var/heimdal/kdc.log showed:
2010-09-21T16:26:36 AS-REQ host/linclient@EXAMPLE from
IPv4:192.168.0.235 for krbtgt/EXAMPLE@EXAMPLE
2010-09-21T16:26:36 No preauth found, returning PREAUTH-REQUIRED --
host/linclient@EXAMPLE
2010-09-21T16:26:36 AS-REQ host/linclient@EXAMPLE from
IPv4:192.168.0.235 for krbtgt/EXAMPLE@EXAMPLE
2010-09-21T16:26:36 No preauth found, returning PREAUTH-REQUIRED --
host/linclient@EXAMPLE
2010-09-21T16:26:36 AS-REQ host/linclient@EXAMPLE from
IPv4:192.168.0.235 for krbtgt/EXAMPLE@EXAMPLE
2010-09-21T16:26:36 No preauth found, returning PREAUTH-REQUIRED --
host/linclient@EXAMPLE
2010-09-21T16:26:36 AS-REQ host/linclient@EXAMPLE from
IPv4:192.168.0.235 for krbtgt/EXAMPLE@EXAMPLE
2010-09-21T16:26:36 No preauth found, returning PREAUTH-REQUIRED --
host/linclient@EXAMPLE
2010-09-21T16:26:36 AS-REQ host/linclient@EXAMPLE from
IPv4:192.168.0.235 for krbtgt/EXAMPLE@EXAMPLE
2010-09-21T16:26:36 No preauth found, returning PREAUTH-REQUIRED --
host/linclient@EXAMPLE
2010-09-21T16:26:36 AS-REQ host/linclient@EXAMPLE from
IPv4:192.168.0.235 for krbtgt/EXAMPLE@EXAMPLE
2010-09-21T16:26:36 No preauth found, returning PREAUTH-REQUIRED --
host/linclient@EXAMPLE
2010-09-21T16:26:36 AS-REQ host/linclient@EXAMPLE from
IPv4:192.168.0.235 for krbtgt/EXAMPLE@EXAMPLE
2010-09-21T16:26:36 No preauth found, returning PREAUTH-REQUIRED --
host/linclient@EXAMPLE
2010-09-21T16:26:36 AS-REQ host/linclient@EXAMPLE from
IPv4:192.168.0.235 for krbtgt/EXAMPLE@EXAMPLE
2010-09-21T16:26:36 No preauth found, returning PREAUTH-REQUIRED --
host/linclient@EXAMPLE
2010-09-21T16:26:36 AS-REQ host/linclient@EXAMPLE from
IPv4:192.168.0.235 for krbtgt/EXAMPLE@EXAMPLE
2010-09-21T16:26:36 No preauth found, returning PREAUTH-REQUIRED --
host/linclient@EXAMPLE
2010-09-21T16:26:36 AS-REQ host/linclient@EXAMPLE from
IPv4:192.168.0.235 for krbtgt/EXAMPLE@EXAMPLE
2010-09-21T16:26:36 No preauth found, returning PREAUTH-REQUIRED --
host/linclient@EXAMPLE
2010-09-21T16:26:36 AS-REQ host/linclient@EXAMPLE from
IPv4:192.168.0.235 for krbtgt/EXAMPLE@EXAMPLE
2010-09-21T16:26:36 No preauth found, returning PREAUTH-REQUIRED --
host/linclient@EXAMPLE
which means that there is
a) some strange "incompatibility" issue with the keytabs provided by
fbsd's heimdal version and the one that linux ships with.
b) the way linux kinit renders a keytab file becomes "problematic" when
des3-cbc-sha1 is absent (on fbsd kinit worked fine with the same
keytab). Haven't setup a linux heimdal server (yet...) to clear this.
but this is a complete different discussion.
The thing is that gssd creates it's krb5 cache in /tmp without any
issues, and dies only after trying to "create context with the server".
This is illustrated below, where gssd is run manually with verbose flags:
destroying client /var/lib/nfs/rpc_pipefs/nfs/clnt49
handling gssd upcall (/var/lib/nfs/rpc_pipefs/nfs/clnt4b)
handle_gssd_upcall: 'mech=krb5 uid=0 enctypes=18,17,16,23,3,1,2 '
handling krb5 upcall (/var/lib/nfs/rpc_pipefs/nfs/clnt4b)
process_krb5_upcall: service is '<null>'
Full hostname for 'filesrv' is 'filesrv'
Full hostname for 'linclient' is 'linclient'
Failed to find root/linclient@EXAMPLE in keytab FILE:/etc/krb5.keytab
(null) while getting keytab entry for 'root/linclient@EXAMPLE'
Failed to find nfs/linclient@EXAMPLE in keytab FILE:/etc/krb5.keytab
(null) while getting keytab entry for 'nfs/linclient@EXAMPLE'
Success getting keytab entry for 'host/linclient@EXAMPLE'
Successfully obtained machine credentials for principal
'host/linclient@EXAMPLE' stored in ccache 'FILE:/tmp/krb5cc_machine_EXAMPLE'
INFO: Credentials in CC 'FILE:/tmp/krb5cc_machine_EXAMPLE' are good
until 1285112422
using FILE:/tmp/krb5cc_machine_EXAMPLE as credentials cache for machine
creds
using gss_krb5_ccache_name to select krb5 ccache
FILE:/tmp/krb5cc_machine_EXAMPLE
creating context using fsuid 0 (save_uid 0)
creating tcp client for server filesrv
DEBUG: port already set to 2049
creating context with server nfs@filesrv
Segmentation fault
The cache in /tmp/krb5cc_machine_EXAMPLE file is ok, since I am able to
klist -c /tmp/krb5cc_machine_EXAMPLE and read its content. The problem
comes after that step, when the client tries to find available
mechanisms (stated in my last email).
2) The second funny thing was that when I searched the list for relevant
problems I found a mail I had sent on the 5th March 2010, where I was
facing some analogous problems, only this time with nfsv4 and a solaris
nfs server. The subject was "mount.nfs4: Broken pipe", and from my
"investigation" that far, I saw that there had to be a mix with MIT and
heimdal on arch-linux. I think that this must be the case now, since
when I read /etc/gssapi_mech.conf, I realized that it discussed about
MIT kerberos5, and /usr/lib/libgssapi.so must be relevant to MIT too.
But pacman -Qo /usr/lib/libgssapi.so showed that it is installed by
heimdal 1.3.3-1...
...I don't know, I am confused! Is there a config
(/etc/conf.d/nfs-common.conf, relevant packages, etc.) with which
someone is able to mount nfsv3 shares using sec=krb5? If anyone is able
to shed some light, it would be reaaally helpful.
Regards,
mamalos
--
George Mamalakis
IT Officer
Electrical and Computer Engineer (Aristotle Un. of Thessaloniki),
MSc (Imperial College of London)
Department of Electrical and Computer Engineering
Faculty of Engineering
Aristotle University of Thessaloniki
phone number : +30 (2310) 994379
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
