8

I'm currently trying to set up an NFSv4 server on FreeBSD. I have extensive experience with doing this on other Unices (Solaris and Linux), but I'm fairly new to FreeBSD.

My goal is to achieve the following:

  • Files served from the FreeBSD system
  • The only security model should be krb5p
  • Clients are Linux (Ubuntu) and OSX

Currently, I have managed to set things up so that I need a valid TGT in order to access the file system. After an attempt to access those files, I can run klist on the client and I can see that the nfs/domainname principal has been retrieved. This suggests that the Kerberos part of the NFS mount is correct.

My problem is that all client accesses are still performed using the nobody user. I can see the permissions when I do ls -l. Even the user mapping works correctly, but unless nobody has permission to do anything with the files, I get a permission denied.

Here's an example interaction from the client (Ubuntu in this case, but the same thing happens from OSX). In this example, /export/shared/testshare is the shared directory from the FreeBSD server:

(I have changed the actual domain name to domain and the Kerberos realm name to REALM)

$ kinit
Password for elias@REALM:
$ klist
Ticket cache: FILE:/tmp/krb5cc_1000_GBjtDP
Default principal: elias@REALM

Valid starting       Expires              Service principal
09/02/2013 09:40:47  10/02/2013 09:40:44  krbtgt/REALM@REALM
$ sudo mount -t nfs4 -osec=krb5p,vers=4 lion:/export/shared/testshare /mnt
$ ls -l /mnt
total 4
-rw-r--r-- 1 nobody nogroup   5 Feb  7 18:17 bar.txt
-rw------- 1 elias  nogroup   4 Feb  5 23:09 foo.txt
$ cat /mnt/bar.txt
blah
$ echo foo >>/mnt/bar.txt
bash: /mnt/bar.txt: Permission denied
$ cat /mnt/foo.txt
cat: /mnt/foo.txt: Permission denied
$ klist
Ticket cache: FILE:/tmp/krb5cc_1000_GBjtDP
Default principal: elias@REALM

Valid starting       Expires              Service principal
09/02/2013 09:40:47  10/02/2013 09:40:44  krbtgt/REALM@REALM
09/02/2013 09:41:56  10/02/2013 09:40:44  nfs/lion.domain@REALM

Server configuration

I have had quite some problems in finding a comprehensive guide to setting up NFSv4 on FreeBSD. This is somewhat surprising in itself as I have found that information on how to do things in FreeBSD to be very good.

Here are the relevant lines in /etc/rc.conf:

rpcbind_enable="YES"
nfs_server_enable="YES"
nfsv4_server_enable="YES"
nfsuserd_enable="YES"
nfscbd_enable="YES"
mountd_enable="YES"
gssd_enable="YES"
rpc_lockd_enable="YES"
rpc_statd_enable="YES"
zfs_enable="YES"

Here is the content of /etc/exports:

/export/shared/testshare -sec=krb5p
V4: / -sec=krb5p

Another interesting aspect is that when I used tcpdump to record the NFS network traffic between the client and the server, I saw NFS3 packets together with the NFS4 packets. Both of these packet types contained encrypted data, so I still think Kerberos was used, but given the configuration above, I would have expected there to be nothing but NFS4 traffic.

Elias Mårtenson
  • 309
  • 1
  • 4
  • 12

3 Answers3

0
  1. Need to disable nfs3 with vfs.nfsd.server_min_nfsvers=4.
  2. To avoid "nobody", NFSv4 client and server should be in the same domain realm.
igelkott
  • 233
  • 3
  • 8
0

Simply put, there has to be some way to map usernames between the systems. Are you running idmapd on both server and client? Ldap?

At least as a test, try making specific mappings between names ... other than root, at least initially.

igelkott
  • 233
  • 3
  • 8
0

I solved the problem. After going through the code I found that the cause was a bug in the GSS library. The problem was caused by a buffer sent to getpwnam_r that was too small.

All the details can be found in the discussion on the mailing list

Elias Mårtenson
  • 309
  • 1
  • 4
  • 12