0

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?

  • 1
    If you only define one client, there should be no access from any other one. And by giving the complete IP, you do not need the '@'. – ridgy Jun 28 '17 at 14:22
  • @ridgy I'll try taking out the '@', but the man page does indicate it even for a single IP. I think it's to signal that it's not a hostname. 10.0.23.43 could be a valid hostname if someone gets crazy enough to pay $185,000 for .43 and ICANN gets crazy enough to approve. :) – Kevin Jun 28 '17 at 21:19
0

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).

|improve this answer|||||
  • Feel free to incorporate the comments into your answer, as comments can be deleted, making this answer much less useful. – Jeff Schaller Jun 28 '17 at 19:11
0

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.)

|improve this answer|||||
  • Did you see this part of the man page for share_nfs: The list is searched sequentially until a match is found that either grants or denies access I suspect that if you had reversed your list to rw=@10.0.23.43,none=* it may have worked as you intended. – Andrew Henle Jun 29 '17 at 19:13
  • 1
    The documentation indeed is not consistent. Especially for ZFS, there is docs.oracle.com/cd/E23824_01/html/821-1448/gayne.html, which refers to docs.oracle.com/cd/E23824_01/html/821-1462/… somewhere. But at the options section, none= is only specified for smb, not for nfs. This seems to be sort of "Try and Error". – ridgy Jun 29 '17 at 21:41
  • @AndrewHenle I did see that statement, which by context applies to the contents of the access list given to the rw, ro, or none option, as opposed to the order of those options themselves. Nevertheless I did try reversing the options as in your example and the outcome was the same. – Kevin Jun 30 '17 at 10:46
  • @Kevin Well, it's either a bug or you've just been welcomed to Solaris documentation. If it's not a bug, the behavior you're seeing almost certainly is documented somewhere in the documentation, but it's likely to be a footnote, obscure example, or a parenthetical expression on a man page at best peripherally related to sharing over NFS. The only way to find it is to know where it is in the first place, or open a support ticket and be told where it's documented. The newer, Oracle-era additions to Solaris also don't seem to be as rigorously documented as the Sun-legacy parts. – Andrew Henle Jun 30 '17 at 12:10
  • @AndrewHenle Yup, definitely have been experiencing that welcome! :) – Kevin Jul 5 '17 at 19:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.