c




 
c



c



 
Author: Piet Plomp

Revision: $Revision: 446 $ ($Date: 2011-03-23 11:11:17 +0100 (Wed, 23 Mar 2011) $)

c  

The candidate should be able to create an exports file and specify filesystems to be exported.
This objective includes editing exports file entries to restrict access to certain hosts, subnets or
netgroups. Also included is specifying mount options in the exports file, configuring user ID
mapping, mounting an NFS filesystem on a client and using mount options to specify soft or
hard and background retries, signal handling, locking and block size. The candidate should
also be able to configure tcp wrappers to further secure NFS.

Key files, terms and utilities include:

The file  
  


The   command
The  ! 
 command
The
 command

"#  $
%!

The abbreviation NFS expands to m
 


. With NFS you can make a remote
disk (or only some of it) part of your local filesystem.

The NFS protocol is currently being reworked, a process which has, so far, taken several
years. This has consequences for those using NFS. Modern NFS daemons will currently run
in    (part of the running kernel) and support version 3 of the NFS protocol
(version 2 will still be supported for compatibility with older clients). Older NFS daemons
running in   (which is almost independent of the kernel) and accepting only protocol
version 2 NFS requests, will still be around. This section will primarily describe kernel-space
NFS-servers supporting protocol version 3 and compatible clients. Differences from older
versions will be pointed out when appropriate.



Details about this NFS work-in-progress are in the section called ³NFS protocol versions´
below.

c
&   '

The system that makes filesystem(s) available to other systems is called a   . The system
that connects to a server is called a   
. Each system can be configured as server, client or
both.





This section describes NFS-related software and its configuration.

()!
 


To run NFS, the following is needed:

ß? support for NFS (several options) must be built into the  

ß? a 
  must be running
ß? on systems with NFS-server support, an m
  and a 
  must be
active
ß? support daemons may be needed

Each is discussed in detail below.

c

$
 


When configuring a kernel for NFS, it must be decided whether or not the system will be a
client or a server. A system with a kernel that contains NFS-server support can also be used as
an NFS client.



The situation described here is valid for the 2.4.È kernel series. Specifications described here
may change in the future.

"*$
 


NFS file system support (c

 )

If you want to use NFS as a client, select this. If this is the only NFS option selected,
the system will support NFS protocol version 2 only. To use protocol version 3 you
will also need to select c

 . When c

 is selected, support
for an old-fashioned user-space NFS-   (protocol version 2) is also present. You
can do without this option when the system is a kernel-space NFS-server server only
(i.e., neither client nor user-space NFS-server).

Provide NFSv3 client support (c

 )

Select this if the client system should be able to make NFS connections to an NFS
version 3 server. This can only be selected if NFS support (c

 ) is also
selected.

NFS server support ( c

 ) Kernel space only.

 When you select this, you get a    NFS-server supporting NFS protocol
version 2. Additional software is needed to control the kernel-space NFS-server (as
will be shown later). To run an old-fashioned user-space NFS-server this option is not
needed. Select c

 instead.

Provide NFSv3 server support (c

  )

This option adds support for version 3 of the NFS protocol to the kernel-space NFS-
server. The kernel-space NFS-server will support both version 2 and 3 of the NFS
protocol. You can only select this if you also select NFS server support
(c

 ).

When configuring during a compiler build (i.e., make menuconfig, make xconfig, etc), the
options listed above can be found in the  

 section, subsection m
 


.

Table 9.1, ³Kernel options for NFS´ provides an overview of NFS support in the kernel.

#+,
 
 



-
 
  . *

NFS file system c


allows both NFS (v2) client and user
support space NFS (v2) server
NFSv3 client c

 and allows NFS (v2 + v3) client
support c


NFS server support c

 provides NFS (v2) kernel server
NFSv3 server c

 and
provides NFS (v2 + v3) kernel server
support c

 

Selecting at least one of the NFS kernel options turns on Sun RPC (Remote Procedure Call)
support automatically. This results in a kernel space RPC input/output daemon. It can be
recognised as

in the process listing.

# !

The portmapper is needed for all NFS traffic [14].

Most distributions will install the portmapper if NFS software (other than the kernel) is being
installed.

The portmapper itself need not be configured. Portmapper security, however,  an issue: you
are strongly advised to limit access to the portmapper. This can be done using the tcp
wrapper.


 !
First, make sure the portmapper has support for the tcp wrapper built in. You can test this by
running **.
. ! [15]. The result could be something like

????  ?
?     ? ?

????  ?
?     ? ?
???? ?
?    ? ?
????     ?
?     ? ?

The line with   (libwrap belongs to the tcp wrapper) shows that this portmapper
is compiled with tcp-wrapper support. If that line is missing, get a better portmapper or
compile one yourself.

A common security-strategy is blocking incoming portmapper requests by default, but

allowing specific hosts to connect. This strategy will be described here.

Start by editing the file  
 
  and adding the following line:

????
 ? ?
?????????? ?

This denies every system access to the portmapper. It can be extended with a command:

????
 ?? ?  ??  
????  ?
? ?

?????????? ?

Now all portmapper requests are denied. In the second example, requests are denied and
reported to root.

The next step is allowing only those systems access that  allowed to do so. This is done by
putting a line in  
 
  :

????
 ? ?
?????????? ?

This allows each host with an IP address starting with the numbers shown to connect to the
portmapper and, therefore, use NFS. Another possibility is specifying part of a hostname:

????
 ?    ?

?????????? ?

This allows all hosts inside the example.com domain to connect. To allow all hosts of a NIS
workgroup:

????
 ?


 ?
?????????? ?

To allow hosts with IP addresses in a subnet:

????
 ?  !!!!!! ?

?????????? ?

This allows all hosts from 192.168.24.16 to 192.168.24.23 to connect (examples from
[Zadok01]).
†

*!


#

$

NFS is implemented as a set of daemons. These can be recognized by their name: they all
start with the  prefix followed by the name of the daemon. Among these are: 
(only a support program in systems with a kernel NFS server), 
,   and


.

The source for these daemons can be found in the 
  package (see [NFS] for more
information on nfs-utils). It will also contain the source of other support programs, such as
 ,  ! 
 and
. These will be discussed later in the section called
³Exporting filesystems´ and the section called ³Testing NFS´.

Distributions may provide 
  as a ready-to-use package, sometimes under different

names. Debian, for example, provides lock and status daemons in a special 
package, and the NFS and mount daemons in " #  packages (which come in user-
space and kernel-space versions).

Each of the daemons mentioned here can also be secured using the tcp wrapper. Details in the
section called ³Securing NFS´.

   

#
*!


When implementing an NFS server, you can install support for an    or an  
 NFS server, depending on the kernel configuration. The 
* command (sometimes
called
*)  the complete NFS server in user space. I kernel space, however, it is just a
support program that can start the NFS server in the kernel.

/$
" "

 

The kernel-space NFS server

The kernel-space NFS server is part of the running kernel. A kernel NFS server
appears as

in the process list.

The version of 
* that supports the NFS server inside the kernel is just a support
program to control NFS kernel server(s).

The user-space NFS daemon

The 
* program can also contain an old-fashioned user-space NFS server
(version 2 only). A user-space NFS server  a complete NFS server. It can be
recognized as  in the process list.

#! 
*!

The ! 
* (or ! 
*) mount-daemon handles incoming NFS (mount) requests. It is
required on a system that provides NFS server support.

The configuration of the mount daemon includes È
 (making available) a filesystem to
certain hosts and specifying how they can use this filesystem.

Exporting filesystems, using the  
  
 file and the   command will be
discussed in the section called ³Exporting filesystems´.

# $*!


A lock daemon for NFS is implemented in  $*.

You won't need lock-daemon support when using modern (2.4.x) kernels. These kernels
provide one internally, which can be recognized as

in the process list. Since the
internal kernel lock-daemon takes precedence, starting  $* accidentally will do no
harm.

There is no configuration for  $*.

#*!


According to the manual page, status daemon * implements only a reboot notification
service. It is a user-space daemon - even on systems with NFS version 3 support. It can be
recognized as 

in the process listing. It is used on systems with NFS client and
NFS server support.

There is no configuration for *.

0 
%!

Exporting a filesystem, or part of it, makes it available for use by another system. A
filesystem can be exported to a single host, a group of hosts or to everyone.

Export definitions are configured in the file  
  
 and will be activated by the
  command. The current export list can be queried with the command  ! 
""
 .



In examples below the system called  will be the NFS server and the system called
  

one of the clients.

#   



The file  
  
 contains the definition(s) of filesystem(s) to be exported, the name of
the host that is allowed to access it and how the host can access it.

Each line in  
  
 has the following format:

????  
?? 


? ?
???????????
?

??t ?i t ?t?

?t??
?

?
??t? t?t ?t
t?i?
ll?t?
? 
?t?t?it ??

t?
??t? t?i?itt?V ?t?
?t? ?
?i ?i
iliti?t?
i ?
? t?
:??

il?t
?

?
??
?t?t
t?i?
ll?t?t?C
?
?
?
?'
??
??

??

il
?

??? t?i?
ll?ll? t?i?t? '

?
i?ill?
?

ll?
?t? '
?il
??

?t?

R
??i?
??
/
t
?
i
ti??

ti?


i?t? t?
t?t ?i?tl ??

?
it??t?C
ti?

l?t?
ll?V ?t?t?t? ?t?ti??
??t
t?t?
i??
i?
t?t? t?
?
?t?i?

?t
t?t
t?t?
ti??

 ?

??
?
?ii?
?
?
?t
ti?it?
?±??
?

ti?
t?

?!ill?
?i?t???
?

M?t
?? t?it?ti?
?

?lit:??

????
   ?'
 
? '
 


?
?????????????????

"l

ti:? t?'
?i?
ll?t?
?
?it?i?

   ? t?
i? '
?
?
ll?t?t?
t?l ?t?
??

c


M
??t?i?
V?t??it?
t?t?t
?
?t?ii
ti?

t?

? ?i?
?lt??i?
t??

????
   ?'
 
?
???????????????

??
????   
 ?  

? ?
?????????????? ?

The first allows   

read and write access. The second allows   

access with
default options (see !
1 ) and  
 read and write access!

0  


Several export options can be used in  
  
 . Only the most important will be
discussed here. See the exports(5) manual page for a full list. Two types of options will be
listed here: general options and user/group id options.

†
 


 (default)

The client(s) has only read access.

The client(s) has read and write access. Of course, the client may choose to mount
read-only anyway.

Also relevant is the way NFS handles user and group permissions across systems. NFS
software considers users with the same UID and the same username as the same users. The
same is true for GIDs.

The user 
is different. Because 
can read (and write) everything [16], root permission
over NFS is considered dangerous.

A solution to this is called : all requests are done as user   (actually UID
!!, often called ) and group   (GID !! ).

At least four options are related to squashing: 
  , 
  ,  

and    . Each will be discussed in detail.

M. *)



  (default)

All requests by user 
on   

(the client) will be done as user   on
 (the server). This implies, for instance, that user 
on the client can only
read files on the server that are    .


 

All requests as 
on the client will be done as 
on the server.

This is necessary when, for instance, backups are to be made over NFS.

This implies that root on  completely trusts user root on   

.
  

Requests of any user other than root on   

are performed as user   on
 .

Use this if you cannot map usernames and UID's easily.

   (default)

All requests of a non-root user on   

are attempted as the same user on
 .

Example entry in  
  
 on system  (the server system):

???? ????  
!$
 ?"    ?

System  allows system   

   access to everything and reads by user
root are done as root on  . Systems from the    domain are allowed  
  access, but requests from root are done as user  , because 
  is true by
default.

Here is an example file:

????? 
  
?? ?

?????
 ?  ?
 ? 
?? 
?? ? ? 
?
?????
?
?  
?? ? 
! ?
?
???? ?  
 $
  ?
???? ?  
 $
  ?
???? ?  
 $
  ?
????  ?  
 $
  ?

Explanation:   
 ,   
 and   
 are allowed to mount the complete filesystem
( : root). But they have read-only access and requests are done as user   . The host
  
is only allowed to mount the   directory with the same rights as the other three
hosts.

#  !!
*

Once  
  
 is configured, the export list in it can be activated using the  
command. It can also be used to reload the list after a change or deactivate the export list.
Table 9.2, ³Overview of exportfs´ shows some of the functionality of  .

#2     

c !!
* -

  reexport all directories
  export or unexport all directories
  de-activate the export list (unexport all)
 

Older (user-space) NFS systems may not have the   command. On these systems the
export list will be installed automatically by the mount daemon when it is started. Reloading
after a change is done by sending a  signal to the running mount-daemon process.

/ 

 

The export list is activated (or reactivated) with the following command:

???? 
??

The  originates from the word   È
.

Before the  " is issued, no filesystems are exported and no other system can connect.

When the export list is activated, the kernel export table will be filled. The following
command will show the kernel export table:

????
?     
 ?

The output will look something like:

????? ? ?
?????
?c  
 ??  ?
???? ???  
 $
 $ $ ?? % ?
????  ???  
 $
 $ $ ?? % ?
???? ???  
 $
 $ $ ?? % ?
???? ???  
 $
 $ $ ?? % ?

Explanation: all named hosts are allowed to mount the root directory (  
:   ) of this
machine with the listed options. The IP addresses are listed for convenience.

Also use  " after you have made changes to  
  
 on a running system.

4



When running  ", some things will be done in the directory  #     . Files
there are easy to corrupt by human intervention with far-reaching consequences, as I have
learned from personal experience.

- 

 

All active export entries are unexported with the command:

???? 
? ?

The letters  are an abbreviation for  È
 .

After the  " no exports are active anymore.

# ! 
 !!
*

The  ! 
 shows information about the exported filesystems and active mounts to the
host. Table 9.3, ³Overview of showmount´ shows how  ! 
 can be used.

#32     ! 


c !!
* -

 ! 
 

show active export list
 ! 
 show names of clients with active mounts
 ! 
   
show directories that are mounted by remote clients
 ! 
  show both client-names and directories

 ! 
 accepts a host name as its last argument. If present,  ! 
 will query the
NFS-server on that host. If omitted, the current host will be queried (as in the examples
below, where the current host is called  ).

4 

 
 The currently active export list can be queried with the 

 option:

?????
?  
?

????
? 
?? ?
???? ?  
 $  
 $  
  ?
????  ?  
  ?

The information is more sparse than the output of . ..
.  shown earlier.

4  
 Without parameters,  ! 
 will show names of hosts currently
connected to the system:

?????
?

????
?? ?
????  
  ?

4   
 
 When the   
  option is specified,

 ! 
 will show names of directories that are currently mounted by a remote host:

?????
?   
  ?

????  
 ?? ?
????  ?

4  
 The  ! 
"" command lists both the remote client (hosts)
and the mounted directories:

?????
?  ?

???? ?
?
?? ?
????  
   ?
m
   
 

? #? 
? t?i?
? t?t
t??
?t
ttt?i?t?
?
? ?


??t?
?t?? #?
ilt i? i?ill?
ll ?
?t?
??

? #?lit  t??t?
?
i
t? #?t?i?t?l?
??
li?

?t?ti?
ll?$Cii?t?l?? #%? t?it??
?i?
 
V?
t?t
?i??t??t?t?t?
ttt:?t?
?

??

m

#
ili
it ?it?t?
?
?
?t?il?' ?i?
?i?ti?


?

?i?
t?lt?t?
i
t?

l?
??

?
?
?
ll ??t?t?
?t?il t?t? #:??

????
? ?? 


 

??  

?
?????????
?

i?ii?t?il t? 


??t?t??

??
?

?t?it? 

??t?lit?
?
l??

"
l:?t?t?t??il t?i?i??? t?

?t?t?l
l?
t it??:??

????
? ??

??

#i&ti??t?t?'t?i??t? 
 ??

????
? ??
??

??
?


l?ti?
?i

l?
t?t?
?ti?lt? ?ti?
t?it?
t?
ttt??
ti? #?ti??

v
m
?


????

?
?i?ii?t?t? #?il t?ill?
?t?V 
?!it?t??
ti?t?t?il t?ill?
?
?

il

l??
t?
i?
?iti?i?
t? #??
??

#

?
lt??t? #??i?'
?i? 
?
t?t?
lt??
t?lit?i?
?i?? ?&tti?t
???
t?ill?
??V   ??

#
 ? can also be written as ; ? can also be written as .

&
 and &


The & option specifies the size for read transfers (from server to client). The
& option specifies the opposite direction. A higher number makes data transfers
faster on a reliable network. On a network where many retries are needed, transfers
may become slower.

Default values are either  or and  , depending on your kernel version. Current
kernels accept a maximum of up to  . NFS version 3 over
, which will
probably production-ready by the time you read this, allows a maximum size of
%. This size is defined with
c  in the file
        
 found in the kernel source-archive.

  and


Specifies the transport-layer protocol for the NFS connection. Most NFS version 2
implementations support only  , but
 implementations do exist. NFS version 3
will allow both   and
 (the latter is under active development). Future version 4
will allow only
. See the section called ³NFS protocol versions´.

# 
?

Specifies the NFS version used for the transport (see the section called ³NFS protocol
versions´). Modern versions of ! 
 will use version  by default. Older
implementations that still use version  are probably numerous.





The 
 option specifies the number of minutes to keep on retrying mount-attempts
before giving up. The default is  minutes.

 


The
  option specifies after how much time a mount-attempt times out. The time-
out value is specified in deci-seconds (tenth of a second). The default is % deci-seconds
(0.7 seconds).

  (default) versus 

These options control how hard the system will try.

2  The system will try indefinitely.

  The system will try until an RPC (portmapper) timeout occurs.


 versus 
 (default)

 With these options one is able to control whether the user is allowed to interrupt the
mount-attempt.

 A mount-attempt can be interrupted by the user if 
 is specified.

 A mount-attempt cannot be interrupted by a user if 
 is set. The mount
request can seem to hang for days if 
 has its default value (10000 minutes).

 (default) and 

These options control the  
 facility. It is off by default.

V  This turns on  
: the client first tries to mount in the
foreground. All retries occur in the background.

 All attempts occur in the foreground.

ë 
 is also affected by other options. When 
 is specified, the
mount attempt will be interrupted by a an RPC timeout. This happens, for example,
when either the remote host is down or the portmapper is not running. In a test setting
the backgrounding was only done when a ³connection refused´ occurred.

Options can be combined using comma's:

????
?
???$&
 ?    ?       ?

A preferred combination of options might be:   , 
 and . The mount will be tried
indefinitely, with retries in the background, but can still be interrupted by the user that started
the mount.

Other mount options to consider are 
 ,  
 ,  or even    . See !
+
! 
 and !
1
.

Of course, all these options can also be specified in  
 
 . Be sure to specify the
 
 option if the filesystem should
 be mounted automatically at boot time. The  
option will allow non-root users to perform the mount. This is not default. Example entry in
 
 
 :

????  ?   ???$ 
$ ????? ?

Now every user can do

????
?    ?

You can also use automounters to mount and unmount remote filesystems, however, these are
beyond the scope of this objective.

#


After NFS has been set up, it can be tested. The following tools can help:  ! 
,

 and
.

# ! 
""  !!
*

As shown in the section called ³The  ! 
 command´, the  ! 
"" 
command lists the current exports a server system. This can be used as a quick indication of
the health of the created NFS system. There are more sophisticated ways.


 

The 
 command reports RPC information. This can be used to probe the portmapper on
a local or a remote system or to send pseudo requests.


 4 
%!

The 
 " command lists all registered services the portmapper knows about. Each 
program registers itself at startup with the portmapper, so the names shown correspond to real
daemons (or the kernel equivalents, as is the case for NFS version 3).

It can be used on the server system  to see if the portmapper is functioning:

???? ?# ?
???
?

???????????? ??? ?? ?

This selection of the output shows that this portmapper will accept connections for nfs version
3 on udp.

A full sample output of 
 " on a server system:

??????
???? ?#  ?
???
?
????????????
??????
   ?
???????????? ??????
   ?
???????????? ????%!%??

 ?
????????????
????%! ??

 ?
???????????? ??? ?? ?
???????????? ??? ?? ?
???????????? ??%%??  ?
???????????? ??%%??  ?
???????????? ??%%??  ?
?????!??????? ??%%??
?
?????!???????
??%??
?
?????!??????? ??%%??
?
?????!???????
??%??
?
?????!??????? ??%%??
?
?????!???????
??%??
?

As can be seen in the listing, the portmapper will accept RPC requests for versions 2 and 3 of
the NFS protocol, both on udp.


As can be seen, each RPC service has its own version number. The 
service, for
instance, supports incoming connections for versions 1, 2 or 3 of mountd on both udp and tcp.

It is also possible to probe  (the server system) from a client system, by specifying
the name of the server system after ":

?????? ?

The output, if all is well, of course, will be the same.


 4!$


)

It is possible to test a connection without doing any real work:


 "  



This is like the 
 command to test a network connection. However, 
 " works like
a real rpc/nfs connection, sending a so-called  pseudo request. The " option forces

 to use udp transport. The result of the test on  :

??????? ?
???? ??# ?? ?  ? 
 ?
???? ??# ?? ?  ? 
 ?

The " options will do the same for tcp transport:

?????
?? ?
????? c?  ?
? 
 ?
???? ? ??
? #   ?

This system obviously does have support for nfs on udp, but not on tcp.



In the example output, the number 100003 is used instead of or together with the name .
Name or number can be used in each others place. That is, we could also have written:

??????? ?

#
 !!
*

The
 lists statistics (i.e., counters) about nfs connections. This can be used to see
whether something is going on at all and also to make sure nothing has gone crazy.

Table 9.4, ³Some options for the nfsstat program´ provides an overview of relevant options
for
.

#5 ! 
 
 !

 
  

server -sr -sn -s
  
  
client -cr -cn -c
both -r -n -nr

Sample output from
"
on the server host  :

???? # ??# ?
???? ???????


????


????
??????? ????? ??? ?
??????????????????????????????????????????????????? ?
???? ???????  ????
??????
????? # ?????   ????? ?
????!! !??? ?????????????????????? ??????????????????? ?
???? ??????? ???? ?????? ?????? ????

????? ?
????????????????????????????????????%???????????????? ?
?
???? # ??# ?
???? ???????


????


???? ?????  ?????  ????
?????????????????????????????????????????????????? ?
???? ???????
??????
????? ?????? ???? ?????? ?
???????????????????????????????????????????????????? ?
???? # ????? ??????   ????? ??????? ????   ?
???????????????????????????????????????????????????? ?
????

??????????
???
????? ?
???????????????????????????????????? ?
?????????

The 's under both  headings are the result of the 
 "
 
 command
shown earlier.





NFS security has several unrelated issues. First, the NFS protocol and implementations have
some known weaknesses. NFS file-handles are numbers that should be random, but are not, in
reality. This opens the possibility of making a connection by guessing file-handles. Another
problem is that all NFS data transfer is done as-is. This means that anyone able to listen to a
connection can tap the information (this is called sniffing). Bad mount-point names combined
with human error can be a totally different security risk.

!


Both sniffing and unwanted connection requests can be prevented by limiting access to each
NFS server to a set of known, trusted hosts with trusted users on it: within a small workgroup,
for instance. Tcp-wrapper support or firewall software can be used to limit access to an NFS
server.

#  Earlier (see the section called ³Securing the portmapper´) it was shown
how to limit connections to the portmapper from specific hosts. The same can be done for the
NFS related daemons, i.e., ! 
* and *. If your system runs an old-fashioned
user-space NFS server (i.e., has  in the process list), consider protecting 
*
and possibly  $*, as well. If, on the other hand, your system is running a modern
kernel-based NFS implementation (i.e., has

in the process list), you cannot do this,
since the 
* program is not the one accepting the connections. Make sure tcp-wrapper
support is built into each daemon you want to protect.

    The problem with tcp-wrapper support is that there already is a

connection inside the host when the connection is refused. If a security-related bug exists in
either the tcp-wrapper library (not very likely) or the daemon that contains the support,
unwanted access may be granted. Or worse. Firewall software (e.g., iptables) can make the
kernel block connections before they enter the host. You can consider blocking unwanted
NFS connections at each NFS server host or at the entry point of a network to all but
acceptable hosts. Block at least the portmapper port (111/udp and 111/tcp). Also, considering
blocking 2049/udp and 2049/tcp (NFS connections). You might also want to block other ports
like the ones shown with the 
 " command: for example, the mount daemon ports
32771/udp and 32768/tcp (at least on my system). How to set up a firewall is shown in detail
in Chapter 12,



.

 

!
 

Simple human error in combination with bad naming can also be a security risk. You would
not be the first person to remove a remote directory tree because the mount point was not
easily recognized as such and the remote system was mounted  
.

v 
p

 Mounting a remote filesystem    can prevent accidental erasure.
So, mount read only if at all possible. If you do need to mount a part  
, make the part
that can be written (erased) as small as possible.

-
% ! 
 
  Also, name a mount point so that it can easily be recognized
as a mount point. One of the possibilities is to use a special name:

???? 

  ?

ë
 


Progress is made in NFS software. Although no software can prevent human error, other risks
(e.g., guessable file-handles and sniffing) can be prevented with better software.



NFS version 4 is a new version of the NFS protocol intended to fix all existing problems in
NFS. It is still in the design phase. More about NFS version 4 and differences between the
versions in the section called ³NFS protocol versions´ in a moment.

†
* One of the ways to break in a NFS server is to guess so-called file-
handles. The old (32-bit) file-handles (used in NFS version 2) were rather easy to guess.
Version 3 of the NFS protocol offers improved security by using 64-bit file-handles that are
considerably harder to guess.

6
5%

!
 The upcoming version 4 of the NFS protocol defines
encrypted connections. When the connection is encrypted, getting information by sniffing is
made much harder or even impossible.
2    
 !



Table 9.5, ³Overview of NFS-related programs and files´ provides an overview of the most
important files and software related to NFS.

#12    
"* !
*

 !  *


The kernel provides NFS support
The  !per handles RPC requests
NFS server control (kernel space) or software (user

*
space)
! 
* handles incoming (un)mount requests
The file  
  
 defines which filesystems are exported
The   command (un)exports filesystems
 ! 
""  shows current exports
The 
 command reports RPC information
The
 command reports NFS statistics
 ! 
"" shows active mounts to me (this host)
! 
"
p
 4 p  mounts a remote filesystem
 p
! 
"
" unmounts all remote filesystems

    


Currently, there are a lot of changes in the NFS protocol that can affect the way the system is
set up. Table 9.6, ³Overview of NFS protocol versions´ provides an overview.

#72    
    


    
 c
 $
  * 
 

1 never released
2 becoming obsolete user, kernel udp, some tcp impl. exist
3 new standard kernel udp, tcp: under development
4 future standard kernel tcp

The trends that can be seen in table Table 9.6, ³Overview of NFS protocol versions´ are:
kernel space instead of user space and tcp instead of udp.

/


      Connections over
 (NFS v3,v4, some v2) are
considered better than connections over   (NFS v2,v3). The   option might be the best
on a small, fast network. But
 allows considerably larger packet sizes (& , & ) to be
set. With sizes of 64k,
 connections are reported to be 10% faster than connections over
 , which does not allow sizes that large..