1.\" $NetBSD: exports.5,v 1.14 1998/10/07 14:52:30 christos 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. 226If no host set is specified, the filesystem is exported to everyone. 227The set may be specified in three ways. 228The first way is to list the host name(s) separated by white space. 229(Standard internet ``dot'' addresses may be used in place of names.) 230The second way is to specify a ``netgroup'' as defined in the netgroup file (see 231.Xr netgroup 5 ). 232A netgroup that contains an item that does have a host entry 233is treated like an error. 234The third way is to specify an internet subnetwork using a network and 235network mask that is defined as the set of all hosts with addresses within 236the subnetwork. 237This latter approach requires less overhead within the 238kernel and is recommended for cases where the export line refers to a 239large number of clients within an administrative subnet. 240.Pp 241The first two cases are specified by simply listing the name(s) separated 242by whitespace. 243All names are checked to see if they are ``netgroup'' names 244first and are assumed to be hostnames otherwise. 245Using the full domain specification for a hostname can normally 246circumvent the problem of a host that has the same name as a netgroup. 247The third case is specified by the flag 248.Sm off 249.Fl network No = Sy netname 250.Sm on 251and optionally 252.Sm off 253.Fl mask No = Sy netmask . 254.Sm on 255If the mask is not specified, it will default to the mask for that network 256class (A, B or C; see 257.Xr inet 5 ). 258.Pp 259For example: 260.Bd -literal -offset indent 261/usr /usr/local -maproot=0:10 friends 262/usr -maproot=daemon grumpy.cis.uoguelph.ca 131.104.48.16 263/usr -ro -mapall=nobody 264/u -maproot=bin: -network 131.104.48 -mask 255.255.255.0 265/u2 -maproot=root friends 266/u2 -alldirs -kerb -network cis-net -mask cis-mask 267.Ed 268.Pp 269Given that 270.Sy /usr , 271.Sy /u 272and 273.Sy /u2 274are 275local filesystem mount points, the above example specifies the following: 276.Sy /usr 277is exported to hosts 278.Em friends 279where friends is specified in the netgroup file 280with users mapped to their remote credentials and 281root mapped to uid 0 and group 10. 282It is exported read-write and the hosts in ``friends'' can mount either /usr 283or /usr/local. 284It is exported to 285.Em 131.104.48.16 286and 287.Em grumpy.cis.uoguelph.ca 288with users mapped to their remote credentials and 289root mapped to the user and groups associated with ``daemon''; 290it is exported to the rest of the world as read-only with 291all users mapped to the user and groups associated with ``nobody''. 292.Pp 293.Sy /u 294is exported to all hosts on the subnetwork 295.Em 131.104.48 296with root mapped to the uid for ``bin'' and with no group access. 297.Pp 298.Sy /u2 299is exported to the hosts in ``friends'' with root mapped to uid and groups 300associated with ``root''; 301it is exported to all hosts on network ``cis-net'' allowing mounts at any 302directory within /u2 and mapping all uids to credentials for the principal 303that is authenticated by a Kerberos ticket. 304.Sh FILES 305.Bl -tag -width /etc/exports -compact 306.It Pa /etc/exports 307The default remote mount-point file. 308.El 309.Sh SEE ALSO 310.Xr netgroup 5 , 311.Xr mountd 8 , 312.Xr nfsd 8 , 313.Xr showmount 8 314.Sh BUGS 315The export options are tied to the local mount points in the kernel and 316must be non-contradictory for any exported subdirectory of the local 317server mount point. 318It is recommended that all exported directories within the same server 319filesystem be specified on adjacent lines going down the tree. 320You cannot specify a hostname that is also the name of a netgroup. 321Specifying the full domain specification for a hostname can normally 322circumvent the problem. 323