Each call to a function which retrieves data from a system database
like the password or group database is handled by the Name Service
Switch implementation in the GNU C library. The various services
provided are implemented by independent modules, each of which
naturally varies widely from the other.
The default implementations coming with the GNU C library are by
default conservative and do not use unsafe data. This might be
very costly in some situations, especially when the databases
are large. Some modules allow the system administrator to request
taking shortcuts if these are known to be safe. It is then the
system administrator's responsibility to ensure the assumption
is correct.
There are other modules where the implementation changed over time.
If an implementation used to sacrifize speed for memory consumption
it might create problems if the preference is switched.
The /etc/default/nss file contains a number of variable
assignments. Each variable controls the behavior of one or more
NSS modules. White spaces are ignored. Lines beginning with `#'
are treated as comments.
The variables currently recognized are:
NETID_AUTHORITATIVE =TRUE|FALSE
If set to TRUE, the NIS backend for the
initgroups(3)
function will accept the information
from the netid.byname NIS map as authoritative. This can speed up the
function significantly if the group.byname map is large. The content
of the netid.byname map is used as is. The system administrator has
to make sure it is correctly generated.
SERVICES_AUTHORITATIVE =TRUE|FALSE
If set to TRUE, the NIS backend for the
getservbyname(3)
and
getservbyname_r(3)
function will assume
services.byservicename NIS map exists and is authoritative, particularly
that it contains both keys with /proto and without /proto for both
primary service names and service aliases. The system administrator
has to make sure it is correctly generated.
SETENT_BATCH_READ =TRUE|FALSE
If set to TRUE, the NIS backend for the
setpwent(3)
and
setgrent(3)
functions will read the entire
database at once and then hand out the requests one by one from
memory with every corresponding
getpwent(3)
or
getgrent(3)
call respectively. Otherwise each
getpwent(3)
or
getgrent(3)
call might result into a network communication with the server to get
the next entry.
EXAMPLE
The default configuration corresponds to the
following configuration file:
