Project

General

Profile

Actions

Bug #13846

open

nfs export to IPv6 and IPv4 fails with wrong error message, share_nfs(1M) manpage update requested

Added by Lee Damon over 2 years ago. Updated about 2 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
nfs - NFS server and client
Start date:
Due date:
% Done:

0%

Estimated time:
Difficulty:
Medium
Tags:
Gerrit CR:
External Bug:

Description

I have a new file server with two interfaces. aggr0 has both IPv4 and IPv6 addresses on it 140.XXX.YYY.ZZZ & 2607:AAAA:BBBB:CCCC:0:DDDD:0:EEEE (referenced below as sharing to 140.XXX.YYY.0/24 and 2607:AAAA:BBBB:CCCC::/64). nas_aggr0 has just an IPv4 address (10.XX.YY.ZZ/24).

The host has OmniOS 151038. I set up and exported a filesystem to nas_aggr0 (@10.XX.YY.0/24) but made an error and tried to mount it via aggr0. Instead of getting the expected mount denied error I got an error about "invalid access list entry: 10.XX.YY.0/24". After correcting the mount to go via nas_aggr0 (which had no problems) I did some testing and found that the 'invlaid access list' error was fairly common where it shouldn't have been presented. All of the below tests were done on aggr0 since it is the only one with both IPv4 and IPv6. In some cases "access denied" might have made sense, in some there should not have been any error at all - presuming the mixing of IPv4 and IPv6 addresses was correct. Since the share_nfs(1M) manpage doesn't mention that I can't be sure that I was or wasn't doing it right.

All errors noted here were logged in /var/adm/messages on the file server.

  1. testing exporting just to IPv4 subnet
    sudo zfs set sharenfs='rw=@140.XXX.YYY.0/24' pool0/exporttest0
    v4 mount: mount success, no error logged
    v6 mount: rejected as expected
  1. testing exporting just to IPv6 subnet
    sudo zfs set sharenfs='rw=@[2607:AAAA:BBBB:CCCC::]/64' pool0/exporttest0
    v4 mount: rejected as expected
    v6 mount: mount success, no error logged
  1. testing using both IPv6 and IPv4 subnet addresses (in that order)
    sudo zfs set sharenfs='rw=@[2607:AAAA:BBBB:CCCC::]/64:@140.XXX.YYY.0/24' pool0/exporttest0
    v4 mount: mount fail, error logged:
    "invalid access list entry: [2607:4000:200:110::]/64"
    v6 mount: mount success, no error logged
  1. testing using both IPv4 and IPv6 subnet addresses (reverse order)
    sudo zfs set sharenfs='rw=140.XXX.YYY.0/24:[2607:AAAA:BBBB:CCCC::]/64' pool0/exporttest0
    v4 mount: mount success, no error logged
    v6 mount: mount fail, error printed:
    "invalid access list entry: 140.XXX.YYY.0/24"
  1. testing exporting to a specific host's name
    sudo zfs set sharenfs='rw=specific.host.dom.ain' pool0/exporttest0
    v4 mount: mount success, no error logged
    v6 mount: mount success, no error logged
  1. testing using exporting to that host's specific IP addresses:
    sudo zfs set sharenfs='rw=140.XXX.YYY.ZZZ:[2607:AAAA:BBBB:CCCC:0:DDDD:0:EEEE]' pool0/exporttest0
    v4 mount: mount success, no error logged
    v6 mount: mount fail, error logged:
    "invalid access list entry: 140.XXX.YYY.DDD"

Part of this testing was complicated by share_nfs(1M) manpage not even mentioning IPv6. It would be useful to update the access_list network section to address IPv6, as well as mixing IPv4 and IPv6.

Actions #1

Updated by Yuri Pankov about 2 years ago

Does the mount really fail or simply logs the warning message?

OK, looks like what I did in #5868 had good intentions, but was done in rather stupid way -- you can't expect all access entries to be for the incoming connection's family. More so, the checks should be in sharenfs handler or the like and not in inet_matchaddr (which should really move out of libnsl).

Though given all the above, it's still not considered a fatal error for the mount.

Actions

Also available in: Atom PDF