Project

General

Profile

Bug #6255

incorrect matching of subnets by zfs sharenfs property

Added by dewey hylton over 4 years ago. Updated almost 3 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
-
Start date:
2015-09-21
Due date:
% Done:

0%

Estimated time:
Difficulty:
Medium
Tags:
needs-triage

Description

with nfs client at 10.200.60.21, the following settings result in denied access:

zfs set sharenfs='ro=@10.200.0.0/24:@10.200.84.0/24:@10.200.88.0/24:@10.200.60.0/24:@10.200.43.0/24' hppool/iso
zfs set sharenfs='ro=@10.200.0.0/24:@10.200.84.0/24:@10.200.88.0/24:@10.200.60.0/24:@10.200.43.0/24:10.200.60.21' hppool/iso
zfs set sharenfs='ro=@10.200.0.0/24:@10.200.84.0/24:@10.200.88.0/24:@10.200.60.0/24:@10.200.43.0/24:@10.200.60.21' hppool/iso

my understanding is that 10.200.60.0/24 should have matched the client, as should 10.200.60.21 ...

the following permits access, though is too open:

zfs set sharenfs='ro=@10.200.0.0/16:@10.200.84.0/24:@10.200.88.0/24:@10.200.60.0/24:@10.200.43.0/24:@10.200.60.21' hppool/iso

the difference here is the subnet mask applied to the first entry: 10.200.0.0/16 covers the entire class b address space.

History

#1

Updated by David Pacheco almost 4 years ago

I'm not sure if these are related, but I seem to be running into a similar problem. I had previously been running platform 20140501T225642Z, and I just upgraded to joyent_20160422T185437Z. (I know, that's a big jump.) I used to have a sharenfs property set to limit access only to a few IPs on my home network, but now when that property is set to something other than "rw", nothing can access it.

Here's a concrete example. In the GZ:

[root@e0-3f-49-ad-24-2c /]# zfs create -o sharenfs=rw zones/test
[root@e0-3f-49-ad-24-2c /]# touch /zones/test/foo

And that works from a client (which actually a non-global zone on the same server):

[root@ducky ~]# mount -F nfs 192.168.0.190:/zones/test /mnt
[root@ducky ~]# ls /mnt
foo
[root@ducky ~]# umount /mnt

But this doesn't:

[root@e0-3f-49-ad-24-2c /]# zfs set sharenfs=rw=192.168.0.180 zones/test

because now I get:

[root@ducky ~]# mount -F nfs 192.168.0.190:/zones/test /mnt
nfs mount: mount: /mnt: Permission denied
[root@ducky ~]# ifconfig -a
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
        inet 127.0.0.1 netmask ff000000 
net0: flags=1004843<UP,BROADCAST,RUNNING,MULTICAST,DHCP,IPv4> mtu 1500 index 2
        inet 192.168.0.180 netmask ffffff00 broadcast 192.168.0.255
        ether d2:77:49:e:53:b6 
lo0: flags=2002000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv6,VIRTUAL> mtu 8252 index 1
        inet6 ::1/128 

The system log reports:

2016-04-24T21:58:54+00:00 e0-3f-49-ad-24-2c mountd[3504]: [ID 770583 daemon.error] 192.168.0.180 denied access to /zones/test
#2

Updated by Yuri Pankov almost 4 years ago

IPs/subnets should be prefixed with @, ie, it should be sharenfs=rw=@192.168.0.180, see share_nfs(1M).

#3

Updated by Yuri Pankov over 3 years ago

  • Status changed from New to Feedback
#4

Updated by Yuri Pankov over 3 years ago

Could you please re-test this with recent changes to inet_matchaddr()?

#5

Updated by David Pacheco over 3 years ago

Sorry for the confusion, and thanks for the tip. The @ syntax appears to be working for me. If it's helpful, I can upgrade and test the other syntax as well.

#6

Updated by Yuri Pankov almost 3 years ago

  • Status changed from Feedback to Closed

Closing this as "feedback timeout". Please reopen if the problem still exists.

Also available in: Atom PDF