This is the result from some discussion in some list (can't remember which)

where someone suggested taking the Linux HOW-TOs and make them applicable
to FreeBSD.

Everyone please feel free to add to this framework.

1 files changed, 369 insertions, 0 deletions

diff --git a/misc/Howto/files/patch-nfs b/misc/Howto/files/patch-nfs
new file mode 100644
index 000000000000..441f0636fda0
--- /dev/null
+++ b/misc/Howto/files/patch-nfs
@@ -0,0 +1,369 @@
+--- NFS-HOWTO.sgml.orig	Sat Oct  3 01:30:40 1998
++++ NFS-HOWTO.sgml	Sat Oct  3 02:20:23 1998
+@@ -67,7 +67,7 @@
+ networking and the terms used.  If you don't recognize the terms you
+ can either go back and check the networking HOWTO, wing it, or get a
+ book about TCP/IP network administration to familiarize yourself with
+-TCP/IP.  That's a good idea anyway if you're administrating UNIX/Linux
++TCP/IP.  That's a good idea anyway if you're administrating UNIX
+ machines.  A very good book on the subject is <em>TCP/IP Network
+ Administration</em> by Craig Hunt, published by O'Reilly &amp;
+ Associates, Inc.  And after you've read it and understood it you'll
+@@ -96,7 +96,7 @@
+ skip ahead to the section on <ref id="nfs-client" name="setting up a
+ NFS client">
+ 
+-<p>If you need to set up a non-Linux box as server you will have to
++<p>If you need to set up a non-FreeBSD box as server you will have to
+ read the system manual(s) to discover how to enable NFS serving and
+ export of file systems through NFS.  There is a separate section in
+ this HOWTO on how to do it on many different systems.  After you have
+@@ -109,8 +109,8 @@
+ 
+ <sect1>The portmapper<label id="portmapper">
+ 
+-<p>The portmapper on Linux is called either <tt/portmap/ or
+-<tt/rpc.portmap/.  The man page on my system says it is a "DARPA port
++<p>The portmapper on FreeBSD is called <tt/portmap/.
++The man page on my system says it is a "DARPA port
+ to RPC program number mapper".  It is the first security holes you'll
+ open reading this HOWTO.  Description of how to close one of the holes
+ is in the <ref id="nfs-security" name="security section">.  Which I,
+@@ -157,24 +157,23 @@
+ use./ There is a separate section in this HOWTO about other Unixes
+ <tt/exports/ files.
+ 
+-<p>Now we're set to start mountd (or maybe it's called <tt/rpc.mountd/
+-and then nfsd (which could be called <tt/rpc.nfsd/).  They will both
++<p>Now we're set to start mountd
++and then nfsd.  They will both
+ read the exports file.  
+ 
+ <p>If you edit <tt>/etc/exports</tt> you will have to make sure nfsd
+ and mountd knows that the files have changed.  The traditonal way is
+-to run <tt/exportfs/.  Many Linux distributions lack a exportfs
+-program.  If you're exportfs-less you can install this script on your
++to run <tt/exportfs/.  FreeBSD lacks a exportfs
++program.  Yyou can install this script on your
+ machine:
+ 
+ <code>
+ #!/bin/sh
+-killall -HUP /usr/sbin/rpc.mountd
+-killall -HUP /usr/sbin/rpc.nfsd
++/bin/kill -HUP `/bin/cat /var/run/mountd.pid`
+ echo re-exported file systems
+ </code>
+ 
+-<p>Save it in, say, <tt>/usr/sbin/exportfs</tt>, and don't forget to
++<p>Save it in, say, <tt>/usr/local/sbin/exportfs</tt>, and don't forget to
+ <tt/chmod a+rx/ it.  Now, whenever you change your exports file, you
+ run exportfs after, as root.
+ 
+@@ -221,12 +220,8 @@
+ <sect>Setting up a NFS client<label id="nfs-client">
+ 
+ <p>First you will need a kernel with the NFS file system either
+-compiled in or available as a module.  This is configured before you
+-compile the kernel.  If you have never compiled a kernel before you
+-might need to check the kernel HOWTO and figure it out.  If you're
+-using a very cool distribution (like Red Hat) and you've never fiddled
+-with the kernel or modules on it (and thus ruined it ;-), nfs is
+-likely automagicaly available to you.
++compiled in or available as a module.  This is configured in the GENERIC
++FreeBSD kernel for you.
+ 
+ <p>You can now, at a root prompt, enter a appropriate mount command and
+ the file system will appear.  Continuing the example in the previous
+@@ -259,7 +254,7 @@
+ as this is required:
+ 
+ <code>
+-# device      mountpoint     fs-type     options	      dump fsckorder
++# Device      Mountpoint     FStype      Options	      Dump Pass#    
+ ...
+ eris:/mn/eris/local  /mnt    nfs	rsize=1024,wsize=1024 0	   0
+ ...
+@@ -294,7 +289,7 @@
+ <p>Picking up the previous example, this is now your fstab entry:
+ 
+ <code>
+-# device      mountpoint     fs-type    options                  dump fsckorder
++# Device      Mountpoint     FStype      Options	      Dump Pass#    
+ ...
+ eris:/mn/eris/local  /mnt    nfs	rsize=1024,wsize=1024,hard,intr 0 0
+ ...
+@@ -304,8 +299,8 @@
+ <sect1>Optimizing NFS<label id="optimizing">
+ 
+ <p>Normally, if no rsize and wsize options are specified NFS will read
+-and write in chunks of 4096 or 8192 bytes.  Some combinations of Linux
+-kernels and network cards cannot handle that large blocks, and it
++and write in chunks of 4096 or 8192 bytes.  Some 
++network cards cannot handle that large blocks, and it
+ might not be optimal, anyway.  So we'll want to experiment and find a
+ rsize and wsize that works and is as fast as possible.  You can test
+ the speed of your options with some simple commands.  Given the mount
+@@ -341,7 +336,7 @@
+ have different optimal sizes.  SunOS and Solaris is reputedly a lot
+ faster with 4096 byte blocks than with anything else.
+ 
+-<p>Newer Linux kernels (since 1.3 sometime) perform read-ahead for
++<p>Newer FreeBSD kernels (since 3.0) perform read-ahead for
+ rsizes larger or equal to the machine page size.  On Intel CPUs the
+ page size is 4096 bytes.  Read ahead will <em/significantly/ increase
+ the NFS read performance.  So on a Intel machine you will want 4096
+@@ -355,13 +350,13 @@
+ requests shall not be considered finished before the data written is
+ on a non-volatile medium (normally the disk).  This restricts the
+ write performance somewhat, asynchronous writes will speed NFS writes
+-up.  The Linux nfsd has never done synchronous writes since the Linux
++up.  The FreeBSD nfsd has never done synchronous writes since the FreeBSD
+ file system implementation does not lend itself to this, but on
+-non-Linux servers you can increase the performance this way with this
++non-FreeBSD servers you can increase the performance this way with this
+ in your exports file:
+ 
+ <code>
+-/dir	-async,access=linuxbox
++/dir	-async,access=freebsdbox
+ </code>
+ 
+ <p>or something similar.  Please refer to the exports man page on the
+@@ -587,10 +582,10 @@
+ servers root account.  In the NFSd man page there are several other
+ squash options listed so that you can decide to mistrust whomever you
+ (don't) like on the clients.  You also have options to squash any UID
+-and GID range you want to.  This is described in the Linux NFSd man
++and GID range you want to.  This is described in the FreeBSD NFSd man
+ page.
+ 
+-<p>root_squash is in fact the default with the Linux NFSd, to grant
++<p>root_squash is in fact the default with the FreeBSD NFSd, to grant
+ root access to a filesystem use <tt/no_root_squash/.
+ 
+ <p>Another important thing is to ensure that nfsd checks that all it's
+@@ -598,7 +593,7 @@
+ any old port on the client a user with no special privileges can run a
+ program that's is easy to obtain over the Internet. It talks nfs
+ protocol and will claim that the user is anyone the user wants to be.
+-Spooky.  The Linux nfsd does this check by default, on other OSes you
++Spooky.  The FreeBSD nfsd does this check by default, on other OSes you
+ have to enable this check yourself.  This should be described in the
+ nfsd man page for the OS.
+ 
+@@ -609,74 +604,9 @@
+ 
+ <p>The basic portmapper, in combination with nfsd has a design problem
+ that makes it possible to get to files on NFS servers without any
+-privileges.  Fortunately the portmapper Linux uses is relatively
+-secure against this attack, and can be made more secure by configuring
+-up access lists in two files.
++privileges.  Fortunately the portmapper FreeBSD uses is relatively
++secure against this attack.
+ 
+-<p>First we edit <tt>/etc/hosts.deny</tt>.  It should contain the line
+-
+-<code>
+-portmap: ALL
+-</code>
+-
+-which will deny access to <em/everyone/.  That's a bit drastic
+-perhaps, so we open it again by editing <tt>/etc/hosts.allow</tt>.
+-But first we need to figure out what to put in it.  It should
+-basically list all machines that should have access to your
+-portmapper.  On a run of the mill Linux system there are very few
+-machines that need any access for any reason.  The portmapper
+-administrates nfsd, mountd, ypbind/ypserv, pcnfsd, and 'r' services
+-like ruptime and rusers.  Of these only nfsd, mountd, ypbind/ypserv
+-and perhaps pcnfsd are of any consequence.  All machines that needs to
+-access services on your machine should be allowed to do that.  Let's
+-say that your machines address is 129.240.223.254 and that it lives on
+-the subnet 129.240.223.0 should have access to it (those are terms
+-introduced by the networking HOWTO, go back and refresh your memory if
+-you need to).  Then we write
+-
+-<code>
+-portmap: 129.240.223.0/255.255.255.0
+-</code>
+-
+-in <tt/hosts.allow/.  This is the same as the network address you give
+-to route and the subnet mask you give to ifconfig.  For the device
+-<tt/eth0/ on this machine <tt/ifconfig/ should show
+-
+-<code>
+-...
+-eth0      Link encap:10Mbps Ethernet  HWaddr 00:60:8C:96:D5:56
+-          inet addr:129.240.223.254  Bcast:129.240.223.255  Mask:255.255.255.0
+-          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
+-          RX packets:360315 errors:0 dropped:0 overruns:0
+-          TX packets:179274 errors:0 dropped:0 overruns:0
+-          Interrupt:10 Base address:0x320 
+-...
+-</code>
+-
+-and <tt/netstat -rn/ should show
+-
+-<code>
+-Kernel routing table
+-Destination     Gateway         Genmask         Flags Metric Ref Use    Iface
+-...
+-129.240.223.0   0.0.0.0         255.255.255.0   U     0      0   174412 eth0
+-...
+-</code>
+-
+-(Network address in first column).
+-
+-The <tt/hosts.deny/ and <tt/hosts.allow/ files are described in the
+-manual pages of the same names.
+-
+-<p><bf/IMPORTANT:/ Do <em/not/ put <em/anything/ but <em/IP NUMBERS/ in
+-the portmap lines of these files.  Host name lookups can indirectly
+-cause portmap activity which will trigger host name lookups which can
+-indirectly cause portmap activity which will trigger...
+-
+-<p>The above things should make your server tighter.  The only
+-remaining problem (Yeah, right!) is someone breaking root (or boot
+-MS-DOS) on a trusted machine and using that privilege to send requests
+-from a secure port as any user they want to be.
+ 
+ <sect1>NFS and firewalls<label id="security-firewalls">
+ 
+@@ -692,13 +622,13 @@
+ 
+ <sect1>Summary<label id="security-summary">
+ 
+-<p>If you use the hosts.allow/deny, root_squash, nosuid and privileged
++<p>If you use the nosuid and privileged
+ port features in the portmapper/nfs software you avoid many of the
+ presently known bugs in nfs and can almost feel secure about <em/that/
+ at least.  But still, after all that: When an intruder has access to
+ your network, s/he can make strange commands appear in your
+ <tt/.forward/ or mailbox file when <tt>/home</tt> or
+-<tt>/var/spool/mail</tt> are mounted over NFS.  For the same reason,
++<tt>/var/mail</tt> are mounted over NFS.  For the same reason,
+ you should never access your PGP private key over nfs.  Or at least
+ you should know the risk involved.  And now you know a bit of it.
+ 
+@@ -706,10 +636,10 @@
+ it's not totally unlikely that new bugs will be discovered, either in
+ the basic design or the implementation we use.  There might even be
+ holes known now, which someone is abusing.  But that's life.  To keep
+-abreast of things like this you should at least read the newsgroups
+-<htmlurl url="news:comp.os.linux.announce"
+-name="comp.os.linux.announce"> and <htmlurl
+-url="news:comp.security.announce" name="comp.security.announce"> at a
++abreast of things like this you should at least read the mailing lists
++<htmlurl url="mailto:freebsd-security@FreeBSD.org"
++name="freebsd-security@FreeBSD.org">
++at a
+ absolute minimum.
+ 
+ <sect>Mount Checklist
+@@ -761,10 +691,7 @@
+ 
+ <p><bf/Fix:/ Get the date set right.
+ 
+-<p>The HOWTO author recommends using NTP to synchronize clocks.  Since
+-there are export restrictions on NTP in the US you have to get NTP for
+-debian, redhat or slackware from
+-ftp://ftp.hacktic.nl/pub/replay/pub/linux or a mirror.
++<p>The HOWTO author recommends using NTP to synchronize clocks.
+ 
+ <item>The server can not accept a mount from a user that is in more
+ than 8 groups.
+@@ -774,93 +701,10 @@
+ 
+ </enum>
+ 
+-<sect>FAQs
+-
+-<p>This is the FAQ section.  Most of it was written by Alan Cox.
+-
+-<enum>
+-
+-  <item>I get a lot of 'stale nfs handle' errors when using Linux as
+-  a nfs server.
+-
+-  <p>This is caused by a bug in some oldish nfsd versions.  It is
+-  fixed in nfs-server2.2beta16 and later.
+-
+-  <item>When I try to mount a file system I get
+-
+-  <tscreen><verb>
+-  can't register with portmap: system error on send
+-  </verb></tscreen>
+-
+-  <p>You are probably using a Caldera system.  There is a bug in the
+-  rc scripts.  Please contact Caldera to obtain a fix.
+-
+-  <item>Why can't I execute a file after copying it to the NFS server?
+-
+-  <p>The reason is that nfsd caches open file handles for performance
+-  reasons (remember, it runs in user space). While nfsd has a file
+-  open (as is the case after writing to it), the kernel won't allow
+-  you to execute it. Nfsds newer than ~spring 95 release open files
+-  after a few seconds, older ones would cling to them for days.
+-
+-  <item>My NFS files are all read only
+-
+-  <p>The Linux NFS server defaults to read only. RTFM the ``exports''
+-  and nfsd manual pages. You will need to alter <tt>/etc/exports</tt>.
+-
+-  <item>I mount from a linux nfs server and while ls works I can't
+-  read or write files.
+-
+-  <p>On older versions of Linux you must mount a NFS servers with
+-  <tt/rsize=1024,wsize=1024/.
+-
+-  <item>I mount from a Linux NFS server with a block size of between
+-  3500-4000 and it crashes the Linux box regularly
+-
+-  <p>Basically don't do it then.
+-
+-  <item>Can Linux do NFS over TCP
+-
+-  <p>No, not at present.
+-
+-  <item>I get loads of strange errors trying to mount a machine from a
+-  Linux box.
+-
+-  <p>Make sure your users are in 8 groups or less. Older servers
+-  require this.
+-
+-  <item>When I reboot my machine it sometimes hangs when trying to
+-  unmount a hung NFS server.
+-
+-  <p>Do <bf/not/ unmount NFS servers when rebooting or halting, just
+-  ignore them, it will not hurt anything if you don't unmount them.
+-  The command is <tt/umount -avt nonfs/.
+-
+-  <item>Linux NFS clients are very slow when writing to Sun and BSD
+-  systems
+-
+-  <p>NFS writes are normally synchronous (you can disable this if you
+-  don't mind risking losing data). Worse still BSD derived kernels
+-  tend to be unable to work in small blocks. Thus when you write 4K of
+-  data from a Linux box in the 1K packets it uses BSD does this
+-
+-  <tscreen><verb>
+-	read 4K page
+-	alter 1K
+-	write 4K back to physical disk
+-	read 4K page
+-	alter 1K
+-	write 4K page back to physical disk
+-	etc..
+-  </verb></tscreen>
+-	
+-</enum>
+-
+-
+ <sect>Exporting filesystems
+ 
+ <p>The way to export filesytems with NFS is not completely consistent
+-across platforms of course.  In this case Linux and Solaris 2 are the
++across platforms of course.  In this case FreeBSD and Solaris 2 are the
+ deviants.  This section lists, superficially the way to do it on most
+ systems.  If the kind of system you have is not covered you must check
+ your OS man-pages.  Keywords are: nfsd, system administration tool, rc