RPC.YPPASSWDD(8)

NAME
rpc.yppasswdd - server for updating NIS passwords

SYNOPSIS
rpc.yppasswdd [-t master.passwd template file] [-d default domain] [-p path] [-s] [-f] [-a] [-m] [-v] [-u] [-h]

DESCRIPTION
The rpc.yppasswdd daemon allows users to change their NIS passwords and certain other information using the yppasswd(1) and ypchpass(1) commands. Rpc.yppasswdd is an RPC-based server that accepts incoming password change requests, authenticates them, places the updated information in the /var/yp/master.passwd template file and then updates the NIS master.passwd and passwd maps.

The rpc.yppasswdd server allows a normal NIS user to change his or her NIS password, full name (also known as 'GECOS' field) or shell. These updates are typically done using the yppasswd(1), ypchfn(1), ypchsh(1), or ypchpass(1) commands. (Some administrators don't want users to be able to change their full name information or shells; the server can be invoked with option flags that disallow such changes.) When the server receives an update request, it compares the address of the client making the request against the securenets rules outlined in /var/yp/securenets. (See the ypserv(8) manual page for more information on securenets; the rpc.yppasswdd server uses the same access control mechanism as ypserv(8) .)

The server then checks the 'old' password supplied by the user to make sure it's valid, then performs some sanity checks on the updated information (these include checking for embedded control characters, colons or invalid shells). Once it is satisfied that the update request is valid, the server modifies the template password file (the default is /var/yp/master.passwd) and then runs the /usr/libexec/yppwupdate script to rebuild the NIS maps. (This script has two arguments passed to it: the absolute pathname of the password template that was modified and the name of the domain that is to be updated. These in turn are passed to /var/yp/Makefile.)

The FreeBSD version of rpc.yppasswdd also allows the super-user on the NIS master server to perform more sophisticated updates on the NIS passwd maps. The super-user can modify any field in any user's master.passwd entry in any domain, and can do so without knowing the user's existing NIS password (when the server receives a request from the super-user, the password authentication check is bypassed). Furthermore, if the server is invoked with the -a flag, the super-user can even add new entries to the maps using ypchpass(1). Again, this only applies to the super-user on the NIS master server: none of these special functions can be peformed over the network.

The rpc.yppasswdd daemon can only be run on a machine that is an NIS master server.

OPTIONS
The following options and flags are supported by rpc.yppasswdd:

-t master.passwd template file
    By default, rpc.yppasswdd assumes that the template file used to generates the master.passwd and passwd maps for the default domain is called /var/yp/master.passwd. This default can be overridden by specifying an alternate file name with the -t flag.

    Note: if the template file specified with this flag is /etc/master.passwd, rpc.yppasswdd will also automatically invoke pwd_mkdb(8) to rebuild the local password databases in addition to the NIS maps.

-d domain
    The rpc.yppasswdd server can support multiple domains, however it must choose one domain as a default. It will try to use the system default domain name as set by the domainname(1) command for this default. However, if the system domain name is not set, a default domain must be specified on the command line. If the system default domain is set, then this option can be used to override it.

-p path
    This option can be used to override the default path to the location of the NIS map databases. The compiled-in default path is /var/yp.

-s  Disallow changing of shell information.

-f  Disallow changing of full name ('GECOS') information.

-a  Allow additions to be made to the NIS passwd databases. The super-user on the NIS master server is permitted to use the ypchpass(1) command to perform unrestricted modifications to any field in a user's master.passwd map entry. When rpc.yppasswdd is started with this flag, it will also allow the super-user to add new records to the NIS passwd maps, just as is possible when using chpass(1) to modify the local password database.

-m  Turn on multi-domain mode. Even though ypserv(8) can handle several simultaneous domains, most implementations of rpc.yppasswdd can only operate on a single NIS domain, which is generally the same as the system default domain of the NIS master server. The FreeBSD rpc.yppasswdd attempts to overcome this problem in spite of the inherent limitations of the yppasswd protocol, which does not allow for a domain argument in client requests. In multi-domain mode, rpc.yppasswdd will search through all the passwd maps of all the domains it can find under /var/yp until it finds an entry that matches the user information specified in a given update request. (Matches are determined by checking the username, UID and GID fields.) The matched entry and corresponding domain are then used for the update.

    Note that in order for multi-domain mode to work, there have to be seperate template files for each domain. For example, if a server supports three domains, foo, bar, and baz, there should be three seperate master.passwd template files called /var/yp/foo/master.passwd, /var/yp/bar/master.passwd, and /var/yp/baz/master.passwd. If foo happens to be the system default domain, then its template file can be either /var/yp/foo/master.passwd or /var/yp/master.passwd. The server will check for the latter file first and then use the former if it can't find it.

    Multi-domain mode is off by default since it can fail if there are duplicate or near-duplicate user entries in different domains. The server will abort an update request if it finds more than one user entry that matches its search criteria. Even so, paranoid administrators may wish to leave multi-domain mode disabled.

-v  Turn on verbose logging mode. The server normally only logs messages using the syslog(3) facility when it encounters an error condition, or when processing updates for the super-user on the NIS master server. Running the server with the -v flag will cause it to log informational messages for all updates.

-u  Many commercial yppasswd(1) clients do not use a reserved port when sending requests to rpc.yppasswdd. This is either because the yppasswd(1) program is not installed set-uid root, or because the RPC implementation does not place any emphasis on binding to reserved ports when establishing client connections for the super-user. By default, rpc.yppasswdd expects to receive requests from clients using reserved ports; requests received from non-privileged ports are rejected. Unfortunately, this behavior prevents any client systems that to not use privileged ports from sucessfully submitting password updates. Specifying the -u flag to rpc.yppasswdd disables the privileged port check so that it will work with yppasswd(1) clients that don't use privileged ports. This reduces security to a certain small degree, but it might be necessary in cases where it is not possible to change the client behavior.

-h  Displays the list of flags and options understood by rpc.yppasswdd.

FILES
/usr/libexec/yppwupdate
    The script invoked by rpc.yppasswdd to update and push the NIS maps after an update.
/var/yp/master.passwd
    The template password file for the default domain.
/var/yp/[domainname]/[maps]
    The NIS maps for a particular NIS domain.
/var/yp/[domainname]/master.passwd
    The template password file(s) for non-default domains (used only in multi-domain mode).

SEE ALSO
ypserv(8), yppush(8), ypxfr(8), yp(4)

BUGS
As listed in the yppasswd.x protocol definition, the YPPASSWDPROC_UPDATE procedure takes two arguments: a V7-style passwd structure containing updated user information and the user's existing unencrypted (cleartext) password. Since rpc.yppasswdd is supposed to handle update requests from remote NIS client machines, this means that yppasswd(1) and similar client programs will in fact be transmitting users' cleartext passwords over the network.

This is not a problem for password updates since the plaintext password sent with the update will no longer be valid once the new encrypted password is put into place, but if the user is only updating his or her 'GECOS' information or shell, then the cleartext password sent with the update will still be valid once the update is completed. If the network is insecure, this cleartext password could be intercepted and used to gain unauthorized access to the user's account.

AUTHOR
Bill Paul <wpaul@ctr.columbia.edu>