The following is not meant to start up a discussion on NFS "security",
as it discusses 2 mechanisms that do not provide real security, but rather
make things harder, so please keep that in mind.

Recently, I changed the NFS code so that its behaviour is as follows:

	1) The use of reserved ports is always checked, for both mount/umount
	   requests and individual NFS RPC calls (default).
	2) The -noresports option is specified for a filesystem/hosts(s) pair,
	   in which case the use of reserved ports is never checked.

This strategy prefers the use of reserved ports to the "filehandle obscurity"
mechanism (yes, both mechanisms are really wrong, but we're stuck with
them for the time being).

The old behaviour was

	3) Always check for reserved ports for mount/umount requests,
	   do not check for reserved ports on individual RPCs (default).
	4) If the -n option is given to the mountd, don't check for
	   reserved ports for mount/umount requests, and also do not
	   check for reserved port use on individual NFS operations.

This strategy uses "filehandle obscurity", only allowing the client to
obtain a filehandle (via the mount request) if it comes from a reserved
port, but not checking later.

Something that came to my mind after I checked this in, is that some people
may want to be able to use the old behaviour, to still rely on filehandle
obscurity and not completely opening up a filesystem using -noresport. Is
this true, and if so, should this be done by

	a) Decoupling the mount/unmount requests from the later NFS operations
	   again, and reinstating the '-n' flag to the mountd? This would
	   have the rather strange effect that you can configure your system
	   to allow mounts from non-reserved ports, but that subsequent
	   operations will fail anyway because they come from non-reserved
	   ports.

	b) Adding a new option to the mountd which says "Always require
	   reserved ports for mount requests, regardless of the usage of
	   -noresport".

Comments?

- Frank