Name

login-process — chain-load utility for recording obsolete login accounting entries

Synopsis

login-process [--id id] {next-prog}

Description

login-process is a chain-loading utility that is used for compatibility with the obsolete /etc/inittab mechanism where login(1) is not properly dealing with login accounting (as modern versions do and should). It chain loads to next-prog with the execvp(3) function.

It determins a terminal character device filename. This can be either a virtual or a real terminal. It primarily expects to inherit this as the value of the TTY environment variable, which it expects to have been set up by a program such as vc-get-tty(1) or pty-get-tty(1). If the environment variable is absent, it calls the ttyname(3) library function.

next-prog may contain its own command line options, which login-process will ignore.

login-process makes no alteration to process state.

BSD behaviour

BSD operating systems have never had /etc/inittab and this command simply does nothing at all. There are simply no or empty "active terminal login" table entries for terminals where no-one is currently logged in; and the active terminal login table is indexed by terminal device (base)name, not by some "id" out of /etc/inittab.

This utility need not be used at all on such operating systems.

Obsolete System 5 behaviour

In the obsolete /etc/inittab system the active terminal login table is indexed by the "id" field from /etc/inittab or by its process ID field, depending from who is doing the lookup. The system manager process only knows the "id" and doesn't know the terminal device name, which isn't a field in /etc/inittab. The various "getty" and "login" programs know their own process IDs, but don't know the "id" field of the /etc/inittab record that spawned them.

The system manager process is expected to have created a utmpx(3) active terminal login table entry of type INIT_PROCESS with the process ID of the forked process and the "id" field from the /etc/inittab record; and the "getty" process (of whatever stripe) is expected to use its process ID to find that record and change it to LOGIN_PROCESS. All this so that the login(1) command can use its process ID to find that record and change it to USER_PROCESS.

login-process emulates this. There simply is no /etc/inittab on systems managed by system-manager(1), systemd, upstart, or other system managers. So it determines a fictitious "id" field from the value of the terminal device name, unless forcibly overridden with the --id command option. There is no fixed convention for this, as there is no enforced convention between IDs and terminal device names in the old /etc/inittab system.

  • It discards any /dev/ or /run/dev/ prefix. In an ideal world, this would be the sole mechanism and the ID would be what results. However, this is not what other softwares, including GUI terminal emulators, do.

  • If the remaining terminal line name begins with "vc" and ends with "/tty", as is conventionally the case with user-space virtual terminals, the ID is the string less the "/tty" suffix.

  • On Linux: if it can discard any further tty, pty, tts, or pts prefixes, the remainder becomes the ID; otherwise, it discards any further non-digit characters up until the first digit character.

So:

  • "/run/dev/vc1/tty" becomes "vc1".

  • "/dev/pts/5" becomes "/5" on Linux and "pts/5" otherwise.

  • "/dev/tty5" becomes "5" on Linux and "tty5" otherwise.

  • "/dev/ttyv5" becomes "v5" on Linux and "ttyv5" otherwise.

Ironically, this song and dance is exactly what GUI terminal emulator programs have already had to do anyway, inventing a nonce "id" and adding new USER_PROCESS records with no existing record to overwrite. Real/virtual terminal login can just take the same approach, and entirely do away with the INIT_PROCESS and LOGIN_PROCESS states like both FreeBSD/DragonFly BSD and GUI terminal emulator programs do. The "login" programs have to wait around for logout anyway, because PAM does not work correctly if there is no session cleanup at logout, and that is where the active terminal login table record should be changed to DEAD_PROCESS too.

It is not in fact necessary at all to use login-process on systems managed by system-manager(1), systemd, upstart, or almost all other system managers.

Security

The program requires permission to read and write to the active terminal login table and append (write) to the terminal login log. Lack of permission will result in the program aborting with an error.

Author

Jonathan de Boyne Pollard