secinfo and so on

[J. Bruce Fields]

This patch series is also available from the server-secinfo branch at

	git://linux-nfs.org/~bfields/linux.git server-secinfo

And there is nfs-utils code to go with it at

	git://linux-nfs.org/~bfields/nfs-utils.git secinfo

(Note: I suspect the nfs-utils code is fine, but I haven't reviewed it
carefully yet.  And the nfs-utils changes aren't split out logically--there's
just one big patch plus some smaller fixes.)

Goals include the following:

1. Allow security flavor requirements to vary based on client ip address.  For
example, you may consider krb5 sufficient on a local network which you believe
to be physically secure, while requiring krb5p for access from elsewhere.  The
/etc/exports syntax looks like:

	/export 192.168.0.0/24(sec=krb5:krb5i:krb5p,rw,...)
	/export              *(sec=krb5p,rw,...)

2. Fix rpcsec_gss for NFSv2 and NFSv3.  Currently v2/v3 krb5 exports only work
if they are also exported with auth_sys.  The fix is to allow auth_sys mount
and nlm requests, since no clients use auth_gss for those protocols.  This
depends on the previous change--we don't want these services suddenly thrown
open to the world without the user doing something new, and users that do
convert to the new setup may want to restrict access by ip address.

3. Implement the NFSv4 secinfo operation.  This fixes a long-standing bug
that, for example, caused Solaris client's mounts to fail when an explicit
security flavor wasn't given on the commandline.

4. Return WRONGSEC (or EACCES, for v2/v3) when traversing into an export
without adequate security, instead of silently ignoring the export and
continuing "underneath" the mountpoint.

5. Return an accurate auth_flavor list in the MNT response.  This isn't done
yet, but it would be trivial at this point.

6. Implement some further exceptions recommended by rfc 2623 to make it easier
for unattended v2/v3 clients to mount krb5-protected exports.  Again, this
hasn't been done yet, but should be fairly straightforward.

We do all this by just associating an ordered list of security flavors to each
export, which is used both to determine access and to generate secinfo
responses.

I prefer this approach because the user<->kernel interface it requires is as
simple as possible and represents the data required by the protocol(s) in a
straightforward way.

However, "struct svc_export" hasn't previously represented an "export"
so much as an entry in an access cache, so this approach does require
some nfsd changes that would otherwise be avoidable--for example,
functions that previously only needed a svc_export, which gave them all
the access information they needed, now need to take a svc_rqst as well,
to allow them to compare the security information on the export with the
security flavor used on the request.

A few of the patches are generic cleanup, so might be worth taking regardless
of the merit of the rest.  I'll resend those later if necessary.

So does that turn out to be horrible?  Brilliant?  Tolerable?  Thoughts
welcomed....

--b.