Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 17 Sep 2010 11:49:15 +0300
From:      George Mamalakis <mamalos@eng.auth.gr>
To:        stable@freebsd.org
Subject:   Re: fbsd8_stable nfsv3 sys=krb5 issue [resolved]
Message-ID:  <4C932B8B.2040705@eng.auth.gr>
In-Reply-To: <4C921F2B.6090101@eng.auth.gr>
References:  <4C921F2B.6090101@eng.auth.gr>

next in thread | previous in thread | raw e-mail | index | archive | help
  On 16/09/2010 16:44, George Mamalakis wrote:
>  Hi all,
>
> I re-decided to move my nfs server from solaris to fbsd. So I am using 
> test machines to see if it works. I have my kerberos realm configured, 
> and seems to work fine, both nfsserver and nfsclient have their host 
> and nfs keytabs stored in /etc/krb5.keytab files, and I am following 
> the configuration instructions from 
> http://code.google.com/p/macnfsv4/wiki/FreeBSD8KerberizedNFSSetup that 
> rick was kind enough to write (thanx rick!). Before analyzing my 
> problem and configuration steps further, let me state the reason for 
> this email: I am not able to access an nfsv3 mounted filesystem when 
> mounted with sys=krb5 (or krb5i, krb5p whatsoever) by following rick's 
> instructions, whereas in the past I had no such problem.
>
> To be more specific:
> Last time I was playing with the configuration most things worked fine 
> (Feb 2010), but now things seem a bit different, and I am not sure 
> whether I have forgotten something fundamental on my configuration or 
> something has changed since I updated both my machines (client and 
> server) to the latest sources:
>
> nfs-server:
> # uname -a
> FreeBSD fbsdclient.ee.auth.gr 8.1-STABLE FreeBSD 8.1-STABLE #1: Wed 
> Sep 15 17:07:13 EEST 2010     
> root@fbsdclient.ee.auth.gr:/usr/obj/usr/src/sys/SERVER  i386
>
> nfs-client:
> # uname -a
> FreeBSD filesrv.ee.auth.gr 8.1-STABLE FreeBSD 8.1-STABLE #0: Fri Sep 
> 10 13:08:06 EEST 2010     
> root@filesrv.ee.auth.gr:/usr/obj/usr/src/sys/CLIENT  amd64
>
> I have my two usual test-users on my test-machines, mamalos and 
> testakis, who both exist as kerberos principals too; their uids and 
> gids are the same on all machines. I am able to kinit to any of them 
> on my machines and acquire a valid kerberos ticket, which makes me 
> assume that kdc runs nicely.
>
> fbsd-client's /etc/rc.conf reads:
>
> rpcbind_enable="YES"
> mountd_enable="YES"
> mountd_flags="-e"
> nfs_server_enable="YES"
> nfs_client_enable="YES"
> nfsv4_server_enable="YES"
> nfsuserd_enable="YES"
> gssd_enable="YES"
>
> and fbsd-server's /etc/rc.conf reads:
> rpcbind_enable="YES"
> nfs_client_flags="-n 4"
> rpc_statd_enable="YES"
> rpc_lockd_enable="YES"
> #nfsd_flags="-e"
> gssd_enable="YES"
> nfsuserd_enable="YES"
> nfsclient_enable="YES"
> # nfs server
> nfs_server_enable="YES"
> mountd_enable="YES"
> #mountd_flags="-e"
>
>
> Don't get confused that both machines have nfsd enabled (the client is 
> used as an experimental nfsv4 server too), and I think that this 
> should not be an issue with regard to my problem (on the other hand, 
> nobody knows...).
>
> the server's kernel-config reads:
>
> options         KGSSAPI
> device          crypto
> options         NFSCL
>
> and the client's kernel-config reads:
>
> options         NFSD   #(don't forget that the client works as an 
> nfsv4 server too)
> options         KGSSAPI
> device          crypto
>
> Lastly, the server's /etc/exports reads:
> /exports    -alldirs -sec=krb5
>
> on the server:
> # ls -la /exports
> total 10
> drwxr-xr-x   5 root      wheel  - 512 17 Feb  2010 ./
> drwxr-xr-x  22 root      wheel  - 512 15 Sep 19:33 ../
> drwxr-xr-x   3 root      wheel  - 512  5 Feb  2010 m/
> drwxr-xr-x   2 mamalos   wheel  - 512 16 Sep 15:43 mamalos/
> drwx------   2 testakis  wheel  - 512  4 Feb  2010 testakis/
>
>
>
> on the client:
> # klist
> klist: No ticket file: /tmp/krb5cc_0
> # mount  mount_nfs -onfsv3,sec=krb5 server:/exports /mnt
> # mount
> /dev/da0s1a on / (ufs, local, soft-updates)
> devfs on /dev (devfs, local, multilabel)
> server:/exports on /mnt (nfs)
> # ls -la /mnt
> total 0
> ls: /mnt: Permission denied
> # exit
> $ id
> uid=1001(mamalos) gid=1001(mamalos) groups=1001(mamalos),0(wheel)
> $ klist
> klist: No ticket file: /tmp/krb5cc_1001
> $ ls -la /mnt
> total 0
> ls: /mnt: Permission denied
> $ kinit mamalos
> mamalos@EXAMPLE's Password:
> $ klist
> Credentials cache: FILE:/tmp/krb5cc_1001
>         Principal: mamalos@EXAMPLE
>
>   Issued           Expires          Principal
> Sep 16 16:26:49  Sep 17 02:26:49  krbtgt/EXAMPLE@EXAMPLE
> $ ls -la /mnt
> total 0
> ls: /mnt: Permission denied
> ...
> (dooea?!?!?!!?)
> ...
> $ klist
> Credentials cache: FILE:/tmp/krb5cc_1001
>         Principal: mamalos@EXAMPLE
>
>   Issued           Expires          Principal
> Sep 16 16:26:49  Sep 17 02:26:49  krbtgt/EXAMPLE@EXAMPLE
> Sep 16 16:27:51  Sep 17 02:26:49  nfs/server@EXAMPLE
>
> And this is where I don't understand what I have done wrong...
> If I use sec=krb5:sys in my /etc/exports, and type mount_nfs 
> -onsfsv3,sec=krb5 ...blabla... on the client, everything seems to work 
> ok, but then again no kerberos "protection" is applicable (I am able 
> to rw in /mnt/mamalos folders as mamalos without having obtained any 
> ticket).
>
> I assume that I must have forgotten to include something very 
> fundamental in my configs, but my head is stuck, so if someone has an 
> idea...
>
> Thank you all for your time in advance,
>
> regards,
>
> mamalos
>
Rick, I found the problem once I followed your suggestion to kinit -k 
fbsdclient.ee.auth.gr on the server; the output was "wrong password" or 
something like that.

On both server and client I have two keys stored in their 
/etc/krb5.keytab files: one nfs/blabla and one host/blabla (due to other 
services I was testing on them). On the server, the first key stored in 
the keytab file was the host/ key and not the nfs/ key. Hence it 
wouldn't accept it (even though the kdc.log wouldn't complain...this I 
still haven't understood so far). Once I placed a single 
/etc/krb5.keytab file containing only the nfs/ key, everything worked as 
should.

Which yields the (natural?) question: Why am I unable to kinit to both 
keys stored in my keytab (I am able to kinit only to the *first* key 
stored in the keytab), even though I have the right to store more than 
one keys in a keytab?

Thanx again, Rick.

-- 
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4C932B8B.2040705>