mirror of
https://git.FreeBSD.org/ports.git
synced 2024-11-06 22:51:41 +00:00
fb6509dd8d
where someone suggested taking the Linux HOW-TOs and make them applicable to FreeBSD. Everyone please feel free to add to this framework.
370 lines
15 KiB
Plaintext
370 lines
15 KiB
Plaintext
--- 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 &
|
|
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
|