+Before reading the configuration file, \become\ predefines a collection of
+classes:
+\begin{itemize}
+\item For every user $u$, a class `$u$' is created containing that user.
+\item For every group $g$, a class `$g$' is created containing all members of
+ that group.
+\item For each netgroup $n$ read from the NIS server, a class `\lit*{u_}$n$'
+ is created containing all the users listed in the netgroup, and a class
+ `\lit{h_}$n$' containing the IP address of all the hosts listed in the
+ netgroup.\footnote{
+ Netgroups don't fit in particularly well with \become's way of thinking.
+ The netgroup idea tries to bind users and hosts together in tight little
+ bundles, which doesn't help here. The current behaviour of splitting
+ the tight little host--user--domain bundles into separate lists of users
+ and hosts is, to the author's knowledge, the cleanest way of making
+ netgroups useful.
+
+ It should probably be pointed out that, in general, NIS should be
+ considered insecure. Nothing too terrible should happen if you run your
+ \become\ server on the NIS master machine.}
+\end{itemize}
+User and group names can contain characters (e.g., dashes or dots) which
+aren't allowed in \become\ class names; \become\ automatically translates
+any non-alphanumeric characters into underscores.
+
+Note that by the end of this process, each class contains the \emph{union} of
+all the things which are automatically put there. So if your system has a
+`root' group, then the class \lit{root} ends up containing the root user
+together with all members of the root group. You can be sure of referring to
+a single user by enclosing the user name in quotes. Hence
+\begin{verbatim}
+ allow HACKERS -> rcs;
+\end{verbatim}
+lets your syshacks become anyone in the rcs group, whereas
+\begin{verbatim}
+ allow HACKERS -> "rcs";
+\end{verbatim}
+lets them become the rcs user only.