If you're the main administrator for a Network Appliance filer, and you did *not* receive the following field alert from NetApp, please let me know. I'm trying to determine whether a wider publication effort is warranted.
This is not a new bug, but it is a critical one.
I discovered it one day (June 8, 2005) on accident, while experimenting with mounts and exports on one of my filers. I dug around in NetApp's NOW site, but didn't find any reference, partly because I didn't know what I was looking for, so I submitted a case. A bit more research revealed the relation to NFSv4, and then I was able to find the bug report on NOW. June 10 is when I suggested that before they close my case, they alert the rest of their customers. It took nearly 30 days for NetApp to finally post a field alert. I think that posting it was the right thing to do, but I'm not pleased that it took so long, and that they hadn't already posted it prior to my discovering it.
---------------------------------------------- From: "Nagabhushan, Dinesh" Dinesh.Nagabhushan@netapp.com Date: Wed, 6 Jul 2005 18:19:34 -0700 Subject: Field Alert #249: NFSv4 does not perform per operation access checks To: bparent@ucsd.edu
Field Alert #249: NFSv4 does not perform per operation access checks
SUMMARY:
There is a defect (Bug 132072) in the NFSv4 implementation of Data ONTAP
releases 6.4 through 6.5.3 that can allow access to exported filesystems
in violation of the settings in the /etc/exports file. The unauthorized
access would occur using NFSv4 only, which is enabled by default on
systems licensed for NFS in Data ONTAP 6.4 and above.
DETAILS:
NFS provides the capability to restrict access to a set of specified
client systems by using the access rw, ro, and root options in the
/etc/exports file or when using the exportfs. The above referenced bug
allows certain NFSv4 clients to bypass these restrictions and connect
from a host that is not listed in the export options. Once the filesystem
is mounted from an unauthorized host, the client has the capability to
perform operations like read, write, or modify data within the filesystem
PROVIDED THAT the standard filesystem permissions and ACLs allow for
those operations to be performed. However, unless the export is
configured to allow ONLY Kerberos authentication, the file permission
lock-down does not help to mitigate the problem (because the user can
choose the UID presented to the filer in the NFS request).
WHO IS AFFECTED:
You are affected if ALL of the following are true:
* You do NOT have bugfix for bug 132072 (i.e. you have Network Appliance
system(s) that are running Data ONTAP versions later than or equal to
6.4 but earlier than 6.5.4) , and
* You have NFS clients in your environment that support NFSv4, and
* NFSv4 is enabled on the above Network Appliance systems. This can be
checked by typing "options nfs.v4.enable" at the command prompt. A
value of "on" indicates that NFSv4 is enabled.
WORK-AROUND:
The workaround is to disable NFSv4 on all filers, NearStore systems,
and ONTAP simulators. This can be accomplished by typing "options
nfs.v4.enable off" at the system console prompt. In the event that you
must use NFSv4 ,it is critical that Kerberos authentication be the
only authentication system enabled. It is not sufficient to simply add
krb5, krb5i, or krb5p to the export configuration; it is also necessary to
ensure that sec=sys is NOT specified.
SOLUTION:
Network Appliance recommends that the workaround of disabling NFSv4 as
stated above be used. Furthermore, if there is an opportunity to upgrade
the systems please upgrade to Data ONTAP 6.5.4 or later. For any further
assistance with upgrading and downloading software, please follow this
link:
http://now.netapp.com/NOW/cgi-bin/software
ADDITIONAL INFORMATION:
Online report for bug 132072
http://now.netapp.com/NOW/cgi-bin/bol?Type=Detail&Display=132072
----------------------------------------------