Solved NFS permissions issue

A

abishai

I have NFS share, looks like it almost works, however I have permission issue.

On a server:
/etc/exports
Code: 
V4: /srv -sec=krb5i:krb5p

/etc/zfs/exports
Code: 
# !!! DO NOT EDIT THIS FILE MANUALLY !!!

/srv/abishai    -sec=krb5i:krb5p
/srv/abishai/darktable    -sec=krb5i:krb5p

ZFS settings
Code: 
zdata/abishai/darktable  aclmode               discard                     default
zdata/abishai/darktable  aclinherit            restricted                  default

/etc/rc.conf
Code: 
nfs_server_enable=YES
nfs_server_flags="-t"
nfsv4_server_only=YES
nfsuserd_enable="YES"
gssd_enable="YES"

On a client:
/etc/rc.conf
Code: 
nfs_client_enable=YES
nfsuserd_enable="YES"
gssd_enable="YES"

Mount command:
mount -o nfsv4,sec=krb5i beta:/abishai/darktable /home/abishai/darktable

My issues are:
1. Client doesn't see permissions.
Server
Code: 
# file: /srv/abishai/darktable/
# owner: abishai
# group: abishai
            owner@:rwxp--aARWcCos:-------:allow
            group@:r-x---a-R-c--s:-------:allow
         everyone@:r-x---a-R-c--s:-------:allow

Client
Code: 
# file: /home/abishai/darktable/
# owner: nobody
# group: nogroup
            owner@:rwxp--aARWcCos:-------:allow
            group@:r-x---a-R-c--s:-------:allow
         everyone@:r-x---a-R-c--s:-------:allow

2. When I copy, every file copied returns an error "No name and/or group mapping for uid,guid:(1001, 1001). 1001 is me and it exists on both server and client. I can see on server, that files have correct permissions.

I suppose, the issue #2 is consequence of issue #1. Because client can't see correct permissions, it's confused and emits false error. I can't say, kerberized NFS setup is well documented, so maybe I made some mistakes?
 
T-Daemon for NFSv4, the user mapping daemon is required. There are no longer numerical uid/gid values on the wire like in NFSv3, but the actual names, so that must be translated.
 
zirias@ said:
T-Daemon for NFSv4, the user mapping daemon is required. There are no longer numerical uid/gid values on the wire like in NFSv3, but the actual names, so that must be translated.
Click to expand...
Reading the manual again, not in any case. nfsuserd(8) must run for kerberized NFSv4 mounts definitely, but not for non-kerberized, when group ID and user ID are the same on server and client(s) (as it was on my test setup), i.e.:
Code: 
 % id abishai
uid=1002(abishai) gid=1002(abishai) groups=1002(abishai)
nfsuserd(8)
Rich (BB code): 
DESCRIPTION
     nfsuserd loads user and group information into the kernel for NFSv4.  For
     Kerberized NFSv4 mounts, it must be running on both client(s) and server
     for correct operation.  For non-Kerberized NFSv4 mounts, this daemon must
     be running unless all client(s) plus the server are configured to put
     uid/gid numbers in the owner and owner_group strings.

Obviously I draw the wrong conclusion. I haven't tested on a kerberized NFS server/client setup, assumed wrongly from my setup nfsuserd(8) isn't needed.

Side note: How much I tried, I couldn't get kerberized NFS to work ever (a failure on my part somewhere, but I couldn't figure out where).

On the other hand NFS-over-TLS works flawless (and IMO is much easier to configure).
 
T-Daemon said:
Side note: How much I tried, I couldn't get kerberized NFS to work ever (a failure on my part somewhere, but I couldn't figure out where).
Click to expand...
I can write how I did it. I almost configured it by myself. if not a stupid error in client's hostname... :)
 
T-Daemon My interpretation of your cited manpage text is that, when NOT using kerberos, you CAN still configure NFS to put (numerical) uids/gids on the wire, although it isn't the default, while as soon as kerberos is used, this is outright impossible. In any case, NFSv4 defaults to putting the usernames there, in which case the mapping is strictly required.

T-Daemon said:
Side note: How much I tried, I couldn't get kerberized NFS to work ever (a failure on my part somewhere, but I couldn't figure out where).
Click to expand...
It shouldn't be too hard though... actually, it worked "out of the box" for me, although my KDC is provided by MIT krb5 integrated with samba (I built samba with different port options for that) and then I found out that for NFS, I must use the heimdal in base (which I didn't even build before) ... still they worked flawlessly together.

The only issue I ran into was using a "host-based initiator" to mount, but that wasn't directly related to kerberos I guess but instead to the LDAP directory. I documented my "journey" here btw: https://sekrit.de/webdocs/freebsd/nfs-jail-kerberos-samba.html

T-Daemon said:
On the other hand NFS-over-TLS works flawless (and IMO is much easier to configure).
Click to expand...
I personally wouldn't consider that, it seems overly complex ...
 
zirias@ said:
I documented my "journey" here btw: https://sekrit.de/webdocs/freebsd/nfs-jail-kerberos-samba.html
Click to expand...
Thank you for pointing the documentation out. The obstacle on my part with kerberized NFS is kerberos. I always get a "permission denied" when trying to mount the share. I suspect I don't get it right to create a valid TGT.


T-Daemon said:
On the other hand NFS-over-TLS works flawless (and IMO is much easier to configure).
Click to expand...
zirias@ said:
I personally wouldn't consider that, it seems overly complex ...
Click to expand...
It's not complex at all. Just enable TLS services on server and client, create a x509v3 certificate, add security option "-tls" to /etc/exports. That's it.

For a basic configuration, on

Server

/etc/rc.conf
Code: 
tlsservd_enable="YES"
tlsservd_flags="-v"   # optional
rpc.tlsservd(8)

/etc/sysctl.conf
Code: 
kern.ipc.tls.enable=1

Create a x509v3 certificate (pair of files, cert.pem, certkey.pem, placed under /etc/rpc.tlsservd. For those who don't know how to, see "Documentation" down below).

/etc/exports
Code: 
V4: /path  -tls

Client

/etc/rc.conf
Code: 
tlsclntd_enable="YES"
rpc.tlsclntd(8)

/etc/sysctl.conf
Code: 
kern.ipc.tls.enable=1

mount -o nfsv4,tls server:/path /mount_point

Check status (look for "tls"): nfsstat -m

Documentation: https://people.freebsd.org/~rmacklem/nfs-over-tls-setup.txt
 
T-Daemon said:
It's not complex at all.
Click to expand...
Uh, all the text following already indicates otherwise, plus you have to do proper X509 certificate management. Kerberos, OTOH, is super simple from the NFS perspective, it works out of the box, but of course requires a working kerberos setup.

SirDice said:
The client "host" machine has to have a host and nfs SPN.
Click to expand...
The nfs SPN is only required for the NFS server, don't add it to other machines.

The client doesn't need anything for mounting as a user in possession of a valid kerberos ticket. But for that, you have to obtain that ticket first, e.g. by logging in on the machine with some PAM module configured to automatically obtain it (krb5, winbind, ...), or by manually doing kinit(1).

For auto-mounting from fstab(5) on boot, that isn't an option, so you can use a "host based initiator" which requires a principal with a key in /etc/krb5.keytab (see ktutil list). This could be any principal, and e.g. Linux' NFS mount tries the HOSTNAME$ one used in Windows AD domains. Unfortunately, FreeBSD's mount_ntf(8) requires a host SPN (host/fqdn) for that. To make this work with a samba AD, I had to "hack" directory entries a bit, as described in the link above.
 
zirias@ said:
Kerberos, OTOH, is super simple from the NFS perspective, it works out of the box, but of course requires a working kerberos setup.
Click to expand...
That's what I mean when saying NFS-over-TLS is not complex to configure.

For kerberized NFS one must configure a KDC server, place on all clients a /etc/krb5.conf, make sure the hostname of the KDC is resolvable in the DNS, eventually set up a DNS server, synchronize time on all hosts/clients with a ntp service, acquire tickets on server and client (did I miss something?) far exceeds the configuration of NFS-over-TLS in the base configuration from the example in post # 9.

As for X509 certificate management, according to https://people.freebsd.org/~rmacklem/nfs-over-tls-setup.txt security/easy-rsa seems to be an suitable tool. I have tested it only a few minutes, however it looks like a qualified tool (from a layman's perspective. I don't have the need for secure connections between machines in my closed, local home network, so I got no experience in this area).


Whatever I try (in a simulated network of VMs), I still get "permission denied" to get a kerberized NFS share mount. Somewhere in the chain with kerberos I have an error, which I am unable to pinpoint.

NFS-over-TLS on the other hand, even a layman like me can have a secure NFS connection between machines with no effort:
Rich (BB code): 
 # mount  -o  nfsv4,tls 192.168.2.21:/nfsShare  /mnt

 # mount | grep /mnt
192.168.2.21:/nfsShare on /mnt (nfs, nfsv4acls)

 # nfsstat -m
192.168.2.21:/nfsShare on /mnt
nfsv4,minorversion=2,tcp,resvport,tls,nconnect=1,hard,cto,sec=sys,acdirmin=3,acdirmax=60,
acregmin=5,acregmax=60,nametimeo=60,negnametimeo=60,rsize=65536,wsize=65536,readdirsize=65536,
readahead=1,wcommitsize=4194304,timeout=120,retrans=2147483647
(Note red highlighted "tls" in the nfsstat(1) output.)
 
T-Daemon said:
NFS-over-TLS on the other hand, even a layman like me can have a secure NFS connection between machines with no effort:
Click to expand...
I have doubts, having seen tons of complaints (in a professional context) about some published API requiring X.509 client certificates (tooling and documents offered) for access, "that's too complicated", "our devs can't get around it" ... :rolleyes:

But that aside: Yes, it offers a "secure connection between machines". That's not what kerberos offers you, where every single filesystem access is authenticated (for the user requesting it). With TLS, your setup is secure as long as you can fully trust every client (IOW, control every client yourself). The client will still tell the server "user foo wants to read /tmp/bar", and the server has no other choice than believe it's really user foo. Kerberos OTOH will require user foo to present a ticket to grant access. BTW, modern SMB has similar mechanisms. NFS without kerberos falls behind, TLS doesn't really fix that. There's a reason it's not an official feature of NFS.
 
You must log in or register to reply here.
Back
Top