The main role of a netgroup is to collect a group of users or a group of hosts under a common name. In doing so, it's possible, and usually a best practice, to structure a composition (by nesting) of netgroups. That is, a netgroup contains a list of users, a list of hosts or a list of other netgroups. It seems clear that there's no one point in creating self-references or cyclical-references.
Being special, a netgroup map has a particular syntax for its value fields, in the form of a triple whose first two components respectively refer to a host and a user. Counter-intuitively, there's absolute no relationship between the first two components of the triple. Although completely unimportant as a practical aspect, in my opinion this is unfortunate, because a relationship could enrich the possibilities, whereas the lack of relationship makes its syntax contradictory to the very natural meaning of a tuple.
By the way, the last field of the triple, depicts the RPC (NIS) domain under consideration and seems specially important when there's no DNS implemented for the network, particularly when dealing with NFSv4 permission options such as rw= referencing a netgroup.
By the way, to more clearly decouple the first and second components, it's recommended to use the "no-value" indicator (a dash, "-") on the unused component. Nevertheless, using it for the last component wouldn't be recommended as it would mean that the triple wouldn't apply to any domain, which probably isn't what's needed in general.
Example:
# ypcat -k netgroup | grep desktop
desktops-10 (dt-10,-,business.corp) (dt-11,-,business.corp) ...
desktops-20 (dt-20,-,business.corp) (dt-21,-,business.corp) ...
desktops dt-10 dt-11 ...
As we can see, desktops is a netgroup composed of two other nested netgroups, desktops-10 and desktops-20. This way, it's possible to break down, preferably by some meaningful grouping, what could otherwise be a very large list. Furthermore, not adopting this technique would imply in very long lines which is likely to hit some line length capacity leading to subtle errors at least when attempting to build the map, so avoid it by all means.
As one final comment, each triple (including its parenthesis) is delimited by one or more spaces or a comma, which might be useful, perhaps, depending on how a particular entry in the netgroup is expected to be parsed by its consumer. In fact I wonder if what's outside the parenthesis is of any relevance at all, but a single space is more than enough for me.
A few useful applications of netgroups are:
- In the aforementioned NFS permissions by means of ro=, rw= and root= NFS export options. But as an exception, unfortunately, netgroups can only be used for the root= option when the NFS security mode is sys. The nfssec(5) man page doesn't say that netgroups can't be used with the ro= and rw= when the NFS security mode options are Kerberos related, such krb5, krb5i, krb5p, or even among others.
Note: When a netgroup is updated, dependent NFS options aren't immediately refreshed, if ever. In order to force the refresh it's necessary to repeat the sharing command ("over" the previous one), a kind of overwrite. If many NFS clients depend on the share, then a mounting storm may happen.
- In the pam_list PAM account management module.
- In the default sudo security policy module (SUDOERS(1m)).
The file location is /etc/sudoers edited by visudo (VISUDO(1m)).
I avoid sudo as much as possible for considering RBAC far superior.
