Just when you thought it was safe...

- getnetgrent.c: address some NIS compatibility problems. We really need
to use the netgroup.byuser and netgroup.byhost maps to speed up innetgr()
when using NIS. Also, change the NIS interaction in the following way:

If /etc/netgroup does not exist or is empty (or contains only the
NIS '+' token), we now use NIS exclusively. This lets us use the
'reverse netgroup' maps and is more or less the behavior of other
platforms.

If /etc/netgroup exists and contains local netgroup data (but no '+').
we use only lthe local stuff and ignore NIS.

If /etc/netgroup exists and contains both local data and the '+',
we use the local data nd the netgroup map as a single combined
database (which, unfortunately, can be slow when the netgroup
database is large). This is what we have been doing up until now.

Head off a potential NULL pointer dereference in the old innetgr()
matching code.

Also fix the way the NIS netgroup map is incorporated into things:
adding the '+' is supposed to make it seem as though the netgroup
database is 'inserted' wherever the '+' is placed. We didn't quite
do it that way before.

(The NetBSD people apparently use a real, honest-to-gosh, netgroup.db
database that works just like the password database. This is
actually a neat idea since netgroups is the sort of thing that
can really benefit from having multi-key search capability,
particularly since reverse lookups require more than a trivial
amount of processing. Should we do something like this too?)

- netgroup.5: document all this stuff.

- rcmd.c: some sleuthing with some test programs linked with my own
version of innetgr() has revealed that SunOS always passes the NIS
domain name to innetgr() in the 'domain' argument. We might as well
do the same (if YP is defined).

- ether_addr.c: also fix the NIS interaction so that placing the
'+' token in the /etc/ethers file makes it seem like the NIS
ethers data is 'inserted' at that point. (Chances are nobody will
notice the effect of this change, which is just te way I like it. :)

1 files changed, 69 insertions, 0 deletions

diff --git a/usr.sbin/mountd/netgroup.5 b/usr.sbin/mountd/netgroup.5
index 9ad8c48..711e04f 100644
--- a/usr.sbin/mountd/netgroup.5
+++ b/usr.sbin/mountd/netgroup.5
@@ -73,6 +73,66 @@ should normally be used to access the
 database.
 .Pp
 Lines that begin with a # are treated as comments.
+.Sh NIS/YP INTERACTION
+On most other platforms,
+.Nm netgroups
+are only used in conjunction with
+NIS and local
+.Pa /etc/netgroup
+files are ignored. With FreeBSD,
+.Nm netgroups
+can be used with either NIS or local files, but there are certain
+caveats to consider. The existing
+.Nm netgroup
+system is extremely inefficient where
+.Fn innetgr 3
+lookups are concerned since
+.Nm netgroup
+memberships are computed on the fly. By contrast, the NIS
+.Nm netgroup
+database consists of three seperate maps (netgroup, netgroup.byuser
+and netgroup.byhost) that are keyed to allow
+.Fn innetgr 3
+lookups to be done quickly. The FreeBSD
+.Nm netgroup
+system can interact with the NIS
+.Nm netgroup
+maps in the following ways:
+.Bl -bullet -offset indent
+.It
+If the
+.Pa /etc/netgroup
+file does not exist, or it exists and is empty, or
+it exists and contains only a '+', and NIS is running,
+.Nm netgroup
+lookups will be done exclusively through NIS, with
+.Fn 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.)
+.It
+If the
+.Pa /etc/netgroup
+exists and contains only local 
+.Nm netgroup
+information (with no NIS '+' token), then only the local
+.Nm netgroup
+information will be processed (and NIS will be ingored).
+.It
+If
+.Pa /etc/netgroup
+exists and contains both local netgroup data
+.Pa and
+the NIS '+' token, the local data and the NIS netgroup
+map will be processed as a single combined
+.Nm netgroup
+database. While this configuration is the most flexible, it
+is also the least efficient: in particular,
+.Fn innetgr 3
+lookups will be especially slow if the
+database is large.
+.El
 .Sh FILES
 .Bl -tag -width /etc/netgroup -compact
 .It Pa /etc/netgroup
@@ -89,3 +149,12 @@ 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.
+.Pp
+The
+.Nm netgroup
+database should be stored in the form of a
+hashed
+.Xr db 3
+database just like the
+.Xr passwd 5
+database to speed up reverse lookups.