mjhjmtu

I'm having trouble getting a Solaris 11.0 server to restrict access to an NFS share to a single client system.

I have roughly the following value for the share property of a tank/mail ZFS filesystem:

name=mail,path=/tank/mail,prot=nfs,none=*,rw=@10.0.23.43,sec=sys

I cannot mount the share on the client (running Solaris 11.3) at 10.0.23.43. I attempt like so:

mount -F nfs keisha:/tank/mail /tmp/mnt

and get the following error:

nfs mount: mount: /tmp/mnt: Permission denied

If I remove none=* then the client mounts fine. However, it is my understanding that doing so will allow access to clients at any address, which I want to prevent (and yes, I'm aware that it may be possible to spoof the address, but prefer to add whatever hoops I can.)

I have tried reversing the order of none and rw, and this changes nothing. I've tried rw=@10.0.23.43/32 and that doesn't work either.

I've tried opening it up to the whole subnet with rw=@10.0.0.0/16 and even that doesn't work. I've also double-checked that I have the client's address right. The client can't be using IPv6 to access the server, as the server's DNS entry is only IPv4 and I'm accessing it by name.

Why does restricting the client addresses prevent access even from a client at an explicitly allowed address? How do I fix this?

Looks like ridgy answered your question, if it's shared to just one host. If you have multiple, using a semi-colon, or creating a netgroup could be used.

If you need/want additional blocking, you could look into using ipfilters or the Solaris Firewall derived from OpenBSD PF (pkg:/network/firewall).

The comment by ridgy hinted at the answer. What was needed was to remove none, leaving:

name=mail,path=/tank/mail,prot=nfs,rw=@10.0.23.43,sec=sys

(It might be possible to omit the @ but the documentation calls for it so I figured it better to leave it in, in case the interpretation becomes more strict in future.)

This is a case of poor documentation. The man page states (emphasis mine):

none

Access is disallowed to all clients. The ro or rw options can override none.

none=access_list

Access is not allowed to any client that matches the access list. The exception is when the access list is an asterisk (*), in which case ro or rw can override none.

Not only does this very explicitly indicate that my client at 10.0.23.43 should have gained access even with none (which it did not,) it also implies that you actually need none in order to avoid clients not listed in rw getting at least some kind of access, because otherwise, why would the override exception for none=* have even (supposedly) been implemented? It would be redundant!

I didn't have any other NFS clients handy to test, so I changed the IP number of my client and confirmed that, indeed, none is not required in order for clients not otherwise listed to be denied access. Just to be sure, I added ro as a test, and my client at a different address could then read but not write.

Though this seems to be the solution, I'm not happy with it, because the documentation implies that what I'm doing is leaving it wide open, and indeed I might be doing just that in a future version that corrects itself to obey the intentions implied by the documentation. (At least I have external firewalls.)