1.\" $NetBSD: exports.5,v 1.13 1997/10/19 15:29:20 fvdl Exp $ 2.\" 3.\" Copyright (c) 1989, 1991, 1993 4.\" The Regents of the University of California. All rights reserved. 5.\" 6.\" Redistribution and use in source and binary forms, with or without 7.\" modification, are permitted provided that the following conditions 8.\" are met: 9.\" 1. Redistributions of source code must retain the above copyright 10.\" notice, this list of conditions and the following disclaimer. 11.\" 2. Redistributions in binary form must reproduce the above copyright 12.\" notice, this list of conditions and the following disclaimer in the 13.\" documentation and/or other materials provided with the distribution. 14.\" 3. All advertising materials mentioning features or use of this software 15.\" must display the following acknowledgement: 16.\" This product includes software developed by the University of 17.\" California, Berkeley and its contributors. 18.\" 4. Neither the name of the University nor the names of its contributors 19.\" may be used to endorse or promote products derived from this software 20.\" without specific prior written permission. 21.\" 22.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND 23.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE 24.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE 25.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE 26.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL 27.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS 28.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) 29.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT 30.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY 31.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF 32.\" SUCH DAMAGE. 33.\" 34.\" @(#)exports.5 8.3 (Berkeley) 3/29/95 35.\" 36.Dd March 29, 1995 37.Dt EXPORTS 5 38.Os 39.Sh NAME 40.Nm exports 41.Nd define remote mount points for 42.Tn NFS 43mount requests 44.Sh SYNOPSIS 45.Nm exports 46.Sh DESCRIPTION 47The 48.Nm exports 49file specifies remote mount points for the 50.Tn NFS 51mount protocol per the 52.Tn NFS 53server specification; see 54.%T "Network File System Protocol Specification \\*(tNRFC\\*(sP 1094, Appendix A" 55and 56.%T "NFS: Network File System Version 3 Specification, Appendix I" . 57.Pp 58Each line in the file 59(other than comment lines that begin with a #) 60specifies the mount point(s) and export flags within one local server 61filesystem for one or more hosts. 62A host may be specified only once for each local filesystem on the 63server and there may be only one default entry for each server 64filesystem that applies to all other hosts. 65The latter exports the filesystem to the ``world'' and should 66be used only when the filesystem contains public information. 67.Pp 68In a mount entry, 69the first field(s) specify the directory path(s) within a server filesystem 70that can be mounted on by the corresponding client(s). 71There are two forms of this specification. 72The first is to list all mount points as absolute 73directory paths separated by whitespace. 74The second is to specify the pathname of the root of the filesystem 75followed by the 76.Fl alldirs 77flag; 78this form allows the host(s) to mount at any point within the filesystem, 79including regular files if the 80.Fl r 81option is used on mountd. Note that the 82.Fl alldirs 83option should not be used as a security measure to make clients mount 84only those subdirectories that they should have access to. A client 85can still access the whole filesystem via individual RPCs if it 86wanted to, even if just one subdirectory has been mounted. 87The pathnames must not have any symbolic links in them and should not have 88any "." or ".." components. 89Mount points for a filesystem may appear on multiple lines each with 90different sets of hosts and export options. 91.Pp 92The second component of a line specifies how the filesystem is to be 93exported to the host set. 94The option flags specify whether the filesystem 95is exported read-only or read-write and how the client uid is mapped to 96user credentials on the server. 97.Pp 98Export options are specified as follows: 99.Pp 100.Sm off 101.Fl maproot No = Sy user 102.Sm on 103The credential of the specified user is used for remote access by root. 104The credential includes all the groups to which the user is a member 105on the local machine (see 106.Xr id 1 ). 107The user may be specified by name or number. 108.Pp 109.Sm off 110.Fl maproot No = Sy user:group1:group2:... 111.Sm on 112The colon separated list is used to specify the precise credential 113to be used for remote access by root. 114The elements of the list may be either names or numbers. 115Note that user: should be used to distinguish a credential containing 116no groups from a complete credential for that user. 117.Pp 118.Sm off 119.Fl mapall No = Sy user 120.Sm on 121or 122.Sm off 123.Fl mapall No = Sy user:group1:group2:... 124.Sm on 125specifies a mapping for all client uids (including root) 126using the same semantics as 127.Fl maproot . 128.Pp 129The option 130.Fl r 131is a synonym for 132.Fl maproot 133in an effort to be backward compatible with older export file formats. 134.Pp 135In the absence of 136.Fl maproot 137and 138.Fl mapall 139options, remote accesses by root will result in using a credential of -2:-2. 140All other users will be mapped to their remote credential. 141If a 142.Fl maproot 143option is given, 144remote access by root will be mapped to that credential instead of -2:-2. 145If a 146.Fl mapall 147option is given, 148all users (including root) will be mapped to that credential in 149place of their own. 150.Pp 151The 152.Fl kerb 153option specifies that the Kerberos authentication server should be 154used to authenticate and map client credentials. 155This option requires that the kernel be built with the NFSKERB option. 156.Pp 157The 158.Fl ro 159option specifies that the filesystem should be exported read-only 160(default read/write). 161The option 162.Fl o 163is a synonym for 164.Fl ro 165in an effort to be backward compatible with older export file formats. 166.Pp 167The 168.Fl noresvport 169option specifies that NFS RPC calls for the filesystem do not have to come 170from reserved ports. Normally, clients are required to use reserved 171ports for operations. Using this option decreases the security of your 172system. 173.Pp 174The 175.Fl noresvmnt 176option specifies that mount RPC requests for the filesystem do not have 177to come from reserved ports. Normally, clients are required to use reserved 178ports for mount requests. Using this option decreases the security of 179your system. 180.Pp 181WebNFS exports strictly according to the spec (RFC 2054 and RFC 2055) can 182be done with the 183.Fl public 184flag. However, this flag in itself allows r/w access to all files in 185the filesystem, not requiring reserved ports and not remapping uids. It 186is only provided to conform to the spec, and should normally not be used. 187For a WebNFS export, 188use the 189.Fl webnfs 190flag, which implies 191.Fl public , 192.Sm off 193.Fl mapall No = Sy nobody 194.Sm on 195and 196.Fl ro . 197.Pp 198A 199.Sm off 200.Fl index No = Sy file 201.Sm off 202option can be used to specify a file whose handle will be returned if 203a directory is looked up using the public filehandle (WebNFS). This 204is to mimic the behavior of URLs. If no 205.Fl index 206option is specified, a directory filehandle will be returned as usual. 207The 208.Fl index 209option only makes sense in combination with the 210.Fl public 211or 212.Fl webnfs 213flags. 214.Pp 215.Bf -symbolic 216Warning: exporting a filesystem both using WebNFS and read/write in 217the normal way to other hosts should be avoided in an environment 218that is vulnerable to IP spoofing. 219.Ef 220WebNFS enables any client to get filehandles to the exported filesystem. 221Using IP spoofing, a client could then pretend to be a host to which 222the same filesystem was exported read/write, and use the handle to 223gain access to that filesystem. 224.Pp 225The third component of a line specifies the host set to which the line applies. 226The set may be specified in three ways. 227The first way is to list the host name(s) separated by white space. 228(Standard internet ``dot'' addresses may be used in place of names.) 229The second way is to specify a ``netgroup'' as defined in the netgroup file (see 230.Xr netgroup 5 ). 231The third way is to specify an internet subnetwork using a network and 232network mask that is defined as the set of all hosts with addresses within 233the subnetwork. 234This latter approach requires less overhead within the 235kernel and is recommended for cases where the export line refers to a 236large number of clients within an administrative subnet. 237.Pp 238The first two cases are specified by simply listing the name(s) separated 239by whitespace. 240All names are checked to see if they are ``netgroup'' names 241first and are assumed to be hostnames otherwise. 242Using the full domain specification for a hostname can normally 243circumvent the problem of a host that has the same name as a netgroup. 244The third case is specified by the flag 245.Sm off 246.Fl network No = Sy netname 247.Sm on 248and optionally 249.Sm off 250.Fl mask No = Sy netmask . 251.Sm on 252If the mask is not specified, it will default to the mask for that network 253class (A, B or C; see 254.Xr inet 5 ). 255.Pp 256For example: 257.Bd -literal -offset indent 258/usr /usr/local -maproot=0:10 friends 259/usr -maproot=daemon grumpy.cis.uoguelph.ca 131.104.48.16 260/usr -ro -mapall=nobody 261/u -maproot=bin: -network 131.104.48 -mask 255.255.255.0 262/u2 -maproot=root friends 263/u2 -alldirs -kerb -network cis-net -mask cis-mask 264.Ed 265.Pp 266Given that 267.Sy /usr , 268.Sy /u 269and 270.Sy /u2 271are 272local filesystem mount points, the above example specifies the following: 273.Sy /usr 274is exported to hosts 275.Em friends 276where friends is specified in the netgroup file 277with users mapped to their remote credentials and 278root mapped to uid 0 and group 10. 279It is exported read-write and the hosts in ``friends'' can mount either /usr 280or /usr/local. 281It is exported to 282.Em 131.104.48.16 283and 284.Em grumpy.cis.uoguelph.ca 285with users mapped to their remote credentials and 286root mapped to the user and groups associated with ``daemon''; 287it is exported to the rest of the world as read-only with 288all users mapped to the user and groups associated with ``nobody''. 289.Pp 290.Sy /u 291is exported to all hosts on the subnetwork 292.Em 131.104.48 293with root mapped to the uid for ``bin'' and with no group access. 294.Pp 295.Sy /u2 296is exported to the hosts in ``friends'' with root mapped to uid and groups 297associated with ``root''; 298it is exported to all hosts on network ``cis-net'' allowing mounts at any 299directory within /u2 and mapping all uids to credentials for the principal 300that is authenticated by a Kerberos ticket. 301.Sh FILES 302.Bl -tag -width /etc/exports -compact 303.It Pa /etc/exports 304The default remote mount-point file. 305.El 306.Sh SEE ALSO 307.Xr netgroup 5 , 308.Xr mountd 8 , 309.Xr nfsd 8 , 310.Xr showmount 8 311.Sh BUGS 312The export options are tied to the local mount points in the kernel and 313must be non-contradictory for any exported subdirectory of the local 314server mount point. 315It is recommended that all exported directories within the same server 316filesystem be specified on adjacent lines going down the tree. 317You cannot specify a hostname that is also the name of a netgroup. 318Specifying the full domain specification for a hostname can normally 319circumvent the problem. 320