X

Casper Dik's Weblog

Solaris 11.3: New per-share, per-instance reserved port property for NFS

Casper Dik
Senior Principal Software Engineer

It sounds like a lifetime ago, that I added the following question to the Solaris FAQ:

7.8) How can I make the NFS server ignore unprivileged clients?

    In a restricted environment, i.e., an environment where the
    administrator controls root access, you can enhance NFS security
    by setting the "NFS_PORTMON" variable.  This variable is set in
    /etc/system, like this:

    * Prior to Solaris 2.5
    set nfs:nfs_portmon = 1

    * Solaris 2.5 and later
    set nfssrv:nfs_portmon = 1

 You could wonder why this was never the default, the answer is that reserved ports are a BSD Unix invention from the time that computers where large and centrally administrated; an invention later copied to all Unix like operating system but outside of that world it makes little sense. As a result, many NFS clients can use any port and might not be able to restrict the ports they use.

The "nfs_portmon" variable was global; Solaris has evolved and now has multiple different NFS server instances (one for each zone); customers also have requested to have a per-share setting.

In Solaris 11.3 we introduce a new sharectl property:

 # sharectl get -p resvport nfs
resvport=false

as well as a new resvport share option:

# zfs get share.nfs.sys.resvport build/casper
NAME          PROPERTY                    VALUE  SOURCE
build/casper  share.nfs.sec.sys.resvport  off    default

The sharectl property is global for the NFS server instance; if it is set to true, this overrides per-share properties.  If a system is upgraded, it will take the value from /etc/system and it will log a message that in future, sharectl(1m) should be used instaed.

When the sharectl property is set to false, you can set resvport for each share individually.  As you can that this is restricted to the "sys" security mode; when proper security such as Kerberos V is used, we do not verify that the NFS client uses privileged ports.

It goes without saying that actual NFS security can only be had when using a security mode other than "sys"

Join the discussion

Comments ( 1 )
  • Steve Kyes Wednesday, August 30, 2017
    Used sharectl to set property nfsmapid_domain to same as dns (resolv.conf domain), /var/run/nfs4_domain, and NetApp nfs.v4.id.domain.
    However, still get "nobody" owner:group ownership.
    This unannounced T* we're benchmarking for Oracle Open World announcement and would like to not have to add 'vers=3' to add the vfstab mount entries.
    Also, once I have updated a "sharectl get nfs" property, how do I blank out.
    Since we have both NFSv3 and v4 NFS mounts on several ldoms, thinking maybe I need to blank this value out:
    nfsmapid_domain=my.domain.com.
    Thanks for any help you can provide!
    This is loaner so can't open MOS SR, and my consultant is on vacation until Tuesday.
    Regards,
    Steve
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.Captcha