On Mon, 24 Mar 1997 19:36:15 -0500
 Perry E. Metzger <perry@piermont.com> writes:

[checking /etc/exports ACLs for each NFS rpc]

>1) way too slow.

Compared to  going to  *disk* ???

I assumed the `normal'' case is an ACL that allows hosts under a
single mask, (e.g., hosts on the same subnet as the NFS server) the
test should be no more expensive than ip_input's test that a packet is
for the local host.

FWIW, I understand that Linux implements nfs daemons at userlevel and
does /etc/exports checks on every NFS RPC request.  The resulting
performance seems adequate to many users.


>> (Or if it's ``too slow'', adding an option to do the
>> checks, defaulting to "do the /exports ACL checks".)

>If you only turn it off all the time, what was the point?

I'm behind a firewall; all the users behind the firewall have the root
password; this test buys me nothing.  *I* could safely turn it off.
I really don't understand at all why you imply that *everyone* would
always turn this option off by default.  To quote an earlier message,

> Its all fine and well to say "Well, NFS is bad, so we should do
> nothing at all for it", but there are real users out there who care
> and don't like the "just @$(%*( 'em" attitude.

In my little corner of the world, border gateways drop packets with
spoofed IP addresses.  That's been the case at every site I've worked
at since 1986.  (That, btw, is why the CMU mobile IP software doesn't
work at Stanford.) Yes, authentication based on IP addreses is a long,
long way from perfect, but that doesn't people from using it, or from
configuring routers to make it a viable option.   In many cases,
IP-address-based security for NFS *is* useful.

I don't see you arguing against mountd using /etc/exports.  After all,
that uses the same security mechanism (access control lists on client
IP addresses) that I proposed for NFS RPCs.

There are other security schemes other than the specific one(s) you
seem to have rather firmly in mind.  Some of them are even quite
viable.  I don't think it makes sense for NetBSD to exclude them from
consideration, just because they don't fit into your particular
environment.