The
file
specifies ``netgroups'', which are sets of
(host, user, domain)
tuples that are to be given similar network access.
Each line in the file
consists of a netgroup name followed by a list of the members of the
netgroup.
Each member can be either the name of another netgroup or a specification
of a tuple as follows:
(host, user, domain)
where the
hostuser
and
domain
are character string names for the corresponding component.
Any of the comma separated fields may be empty to specify a ``wildcard'' value
or may consist of the string ``-'' to specify ``no valid value''.
The members of the list may be separated by whitespace and/or commas;
the ``\'' character may be used at the end of a line to specify
line continuation.
Lines are limited to 1024 characters.
The functions specified in
getnetgrent(3)
should normally be used to access the
database.
Lines that begin with a # are treated as comments.
NIS/YP INTERACTION
On most other platforms,
s
are only used in conjunction with
NIS
and local
/etc/netgroup
files are ignored.
With
Fx ,
s
can be used with either
NIS
or local files, but there are certain
caveats to consider.
The existing
system is extremely inefficient where
innetgr (3);
lookups are concerned since
memberships are computed on the fly.
By contrast, the
NIS
database consists of three separate maps (netgroup, netgroup.byuser
and netgroup.byhost) that are keyed to allow
innetgr (3);
lookups to be done quickly.
The
Fx
system can interact with the
NIS
maps in the following ways:
If the
/etc/netgroup
file does not exist, or it exists and is empty, or
it exists and contains only a
`+'
and
NIS
is running,
lookups will be done exclusively through
NIS
with
innetgr (3);
taking advantage of the netgroup.byuser and
netgroup.byhost maps to speed up searches.
(This
is more or less compatible with the behavior of SunOS and
similar platforms.)
If the
/etc/netgroup
exists and contains only local
information (with no
NIS
`+'
token), then only the local
information will be processed (and
NIS
will be ignored).
If
/etc/netgroup
exists and contains both local netgroup data
and
the
NIS
`+'
token, the local data and the
NIS
netgroup
map will be processed as a single combined
database.
While this configuration is the most flexible, it
is also the least efficient: in particular,
innetgr (3);
lookups will be especially slow if the
database is large.
FILES
/etc/netgroup
the netgroup database
COMPATIBILITY
The file format is compatible with that of various vendors, however it
appears that not all vendors use an identical format.
The interpretation of access restrictions based on the member tuples of a
netgroup is left up to the various network applications.
Also, it is not obvious how the domain specification
applies to the
BSD environment.
The
database should be stored in the form of a
hashed
db(3)
database just like the
passwd(5)
database to speed up reverse lookups.
