xref: /freebsd/usr.sbin/mountd/netgroup.5 (revision a8445737e740901f5f2c8d24c12ef7fc8b00134e)
1.\" Copyright (c) 1992, 1993
2.\"	The Regents of the University of California.  All rights reserved.
3.\"
4.\" Redistribution and use in source and binary forms, with or without
5.\" modification, are permitted provided that the following conditions
6.\" are met:
7.\" 1. Redistributions of source code must retain the above copyright
8.\"    notice, this list of conditions and the following disclaimer.
9.\" 2. Redistributions in binary form must reproduce the above copyright
10.\"    notice, this list of conditions and the following disclaimer in the
11.\"    documentation and/or other materials provided with the distribution.
12.\" 3. All advertising materials mentioning features or use of this software
13.\"    must display the following acknowledgement:
14.\"	This product includes software developed by the University of
15.\"	California, Berkeley and its contributors.
16.\" 4. Neither the name of the University nor the names of its contributors
17.\"    may be used to endorse or promote products derived from this software
18.\"    without specific prior written permission.
19.\"
20.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
21.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
22.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
23.\" ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
24.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
25.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
26.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
27.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
28.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
29.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
30.\" SUCH DAMAGE.
31.\"
32.\"     @(#)netgroup.5	8.2 (Berkeley) 12/11/93
33.\"
34.Dd December 11, 1993
35.Dt NETGROUP 5
36.Os
37.Sh NAME
38.Nm netgroup
39.Nd defines network groups
40.Sh SYNOPSIS
41.Nm netgroup
42.Sh DESCRIPTION
43The
44.Nm
45file
46specifies ``netgroups'', which are sets of
47.Sy (host, user, domain)
48tuples that are to be given similar network access.
49.Pp
50Each line in the file
51consists of a netgroup name followed by a list of the members of the
52netgroup.
53Each member can be either the name of another netgroup or a specification
54of a tuple as follows:
55.Bd -literal -offset indent
56(host, user, domain)
57.Ed
58.Pp
59where the
60.Sy host ,
61.Sy user ,
62and
63.Sy domain
64are character string names for the corresponding component.
65Any of the comma separated fields may be empty to specify a ``wildcard'' value
66or may consist of the string ``-'' to specify ``no valid value''.
67The members of the list may be separated by whitespace and/or commas;
68the ``\e'' character may be used at the end of a line to specify
69line continuation. Lines are limited to 1024 characters.
70The functions specified in
71.Xr getnetgrent 3
72should normally be used to access the
73.Nm
74database.
75.Pp
76Lines that begin with a # are treated as comments.
77.Sh NIS/YP INTERACTION
78On most other platforms,
79.Nm Ns s
80are only used in conjunction with
81.Tn NIS
82and local
83.Pa /etc/netgroup
84files are ignored. With
85.Bx Free ,
86.Nm Ns s
87can be used with either
88.Tn NIS
89or local files, but there are certain
90caveats to consider. The existing
91.Nm
92system is extremely inefficient where
93.Fn innetgr 3
94lookups are concerned since
95.Nm
96memberships are computed on the fly. By contrast, the
97.Tn NIS
98.Nm
99database consists of three separate maps (netgroup, netgroup.byuser
100and netgroup.byhost) that are keyed to allow
101.Fn innetgr 3
102lookups to be done quickly. The
103.Bx Free
104.Nm
105system can interact with the
106.Tn NIS
107.Nm
108maps in the following ways:
109.Bl -bullet -offset indent
110.It
111If the
112.Pa /etc/netgroup
113file does not exist, or it exists and is empty, or
114it exists and contains only a
115.Sq + ,
116and
117.Tn NIS
118is running,
119.Nm
120lookups will be done exclusively through
121.Tn NIS ,
122with
123.Fn innetgr 3
124taking advantage of the netgroup.byuser and
125netgroup.byhost maps to speed up searches. (This
126is more or less compatible with the behavior of SunOS and
127similar platforms.)
128.It
129If the
130.Pa /etc/netgroup
131exists and contains only local
132.Nm
133information (with no
134.Tn NIS
135.Sq +
136token), then only the local
137.Nm
138information will be processed (and
139.Tn NIS
140will be ignored).
141.It
142If
143.Pa /etc/netgroup
144exists and contains both local netgroup data
145.Pa and
146the
147.Tn NIS
148.Sq +
149token, the local data and the
150.Tn NIS
151netgroup
152map will be processed as a single combined
153.Nm
154database. While this configuration is the most flexible, it
155is also the least efficient: in particular,
156.Fn innetgr 3
157lookups will be especially slow if the
158database is large.
159.El
160.Sh FILES
161.Bl -tag -width /etc/netgroup -compact
162.It Pa /etc/netgroup
163the netgroup database
164.El
165.Sh SEE ALSO
166.Xr getnetgrent 3 ,
167.Xr exports 5
168.Sh COMPATIBILITY
169The file format is compatible with that of various vendors, however it
170appears that not all vendors use an identical format.
171.Sh BUGS
172The interpretation of access restrictions based on the member tuples of a
173netgroup is left up to the various network applications.
174Also, it is not obvious how the domain specification
175applies to the
176.Bx
177environment.
178.Pp
179The
180.Nm
181database should be stored in the form of a
182hashed
183.Xr db 3
184database just like the
185.Xr passwd 5
186database to speed up reverse lookups.
187