rlogind — Validate rlogin requests

Description

The rlogind program is the server for the remote login command rlogin commonly found on UNIX systems. It validates the remote login request and verifies the password or password phrase of the target user. It starts a z/OS shell for the user and handles translation between ASCII and EBCDIC code pages as data flows between the workstation and the shell.

The rlogind program is given control via an execl() issued by the inetd daemon.

Rule: Always invoke rlogind from inetd through the /etc/inetd.conf file. Do not invoke it from the shell. inetd sets up certain files and sockets needed by rlogind. Invoking rlogind directly gives unpredictable results.

Options

–a

Specifies that the requester's Internet address be checked against the local gethostbyname() file. This option has no effect because the rlogin program never uses the .rhosts file for authentication.

–d

Specifies that the debugging option be enabled. Informational messages on the rlogin process is written to the system log.

–l

Specifies that the .rhosts file for authentication not be used. This option has no effect because the rlogin program never uses the .rhosts file for authentication.

–L

Allows the calling of a ruserok exit that lives in /usr/sbin. A return code zero will allow bypassing of password or password phrase checking. The installation is responsible for providing the ruserok exit.

Note: IBM® does not recommend using this capability. Using this capability may open security holes, allowing unauthorized users to access and modify files and MVS™ data sets. Even with the most rigorous checking in the ruserok exit, it is important to keep in mind the well-known IP spoofing attacks that make it impossible to accurately identify the remote user's identity.

IBM recommends that the -L flag not be specified. IBM will not accept APARS for security problems resulting from the use of this option.

When the -L flag is specified, /usr/sbin/ruserok is called, passing:

• The name of the program, /usr/sbin/ruserok
• "hostname" or "hostname.domainname" of the client
• A superuser flag, an integer set to 1 if the user wants to be superuser
• Client user name, the username on the client system
• Server user name, the username on this (server's) system

If the ruserokprogram exits with a zero return value, the user is allowed to login. Otherwise, normal password or password phrase checking will be done.

Note: If the facility class is active, and BPX.DAEMON defined, then both inetd's and rlogind's user names must be permitted to BPX.DAEMON and the ruserok program (as well as inetd and rlogind) must be marked program controlled.

–m

Specifies that multiprocessing support in the user's address space be enabled. Using the –m option uses fewer system resources and provides faster performance for the end user.

If you do not specify –m, each rlogin request causes two MVS address spaces to be consumed. The first address space is the rlogind code, which provides the user connection to the socket, and the second is the user's shell. In this mode, all shell functions behave in a manner conformant to the standards.

If you specify –m, the rlogin process and the shell process share the same address space using z/OS UNIX System Services support for multiple processes in an address space. Using –m has the potential of doubling the number of users supported via rlogin.

Note: If you issued rlogind with the –m option, the shell process cannot execute a setuid program that replaces the shell. This causes functions like newgrp to fail. In this situation, you may want to create a secondary shell that runs in its own address space.

–n

Specifies that the transport-level keep-alive messages be disabled. The messages are enabled by default.

Usage notes

1. The rlogind program normally translates all error and warning messages to ASCII and then sends them to the originating terminal.

   However, when the C runtime library writes error messages, the rlogind program cannot intercept them to translate the messages to ASCII. Therefore, these messages are written to the file /tmp/rlogind.stderr or /tmp/rlogind2.stderr.

   These two files must be predefined in /tmp, and owned by the superuser (UID 0). The files should have permissions of rw–rw–rw or rw––w––w–. In addition, the sticky bit must be set for the /tmp directory so that these files (and other files in /tmp) cannot be removed except by the files' owners or the superuser.

2. rlogind is not affected by the locale information specified in locale-related environment variables.

Related information

inetd