console-multiplexor 1 user commands nosh
console-multiplexor realize many user-space virtual terminals on one
`console-multiplexor` --display-only muxname vcname(s)

## Description

`console-multiplexor` multiplexes one or more (user-space) virtual terminals onto a single (user-space) virtual terminal, acting as a realizer for the former.

It opens the character/attribute buffer file(s) `vcname/display` and the input FIFO(s) `vcname/input`. These are the back-end interfaces of the user-space virtual terminal(s) being multiplexed, as detailed in user-vt 5. It does not attempt to create these if they do not exist.

It opens the character/attribute buffer file `muxname/display` and the input FIFO `muxname/input`. These are the back-end interfaces of the single user-space virtual terminal onto which the others are multiplexed, as detailed in user-vt 5. It will create these if they do not exist.

It then enters a loop where it simultaneously:

- (unless the --display-only option is used) writes all data received from the mux input FIFO to the input FIFO for the foreground virtual terminal; and

- renders the contents of the character/attribute buffer file for the foreground virtual terminal on the mux virtual terminal's display buffer.

One virtual terminal is in the foreground. This is the virtual terminal that is currently rendered onto the mux display buffer and to which input events are sent. It is changed in response to special session switch input events, generated by whatever realizer is attached to the mux virtual terminal; and key events for the Next Task, Previous Task, and Task Selection Consumer keypad keys. These events are filtered from the input stream and not passed along to the multiplexed virtual terminals. (The multiplexor also consumes other Consumer keys such as Terminal Lock, Log In, Log Out, Task Manager, and Halt Task. These are reserved for future use.)

Session switch events are generated by realizers and by console-multiplexor-control 1.

Because of the modular nature of user space virtual terminals, there is no notion of an "active" virtual terminal that is visible to the programs that are running on the virtual terminals. Multiple multiplexers and realizers may be attached to the back end of any given virtual terminal; or indeed none may be attached at all. Session switching is commanded by realizers, exacted by multiplexors; and the terminal emulators have no hand in it.

At termination, it truncates the display buffer file in `muxname/`.

## Security

`console-multiplexor` requires no superuser privileges and is designed to be run entirely under the aegis of a dedicated unprivileged user account. It only requires write and search access to `muxname/` and need not have owner access to it. Conversely, only the multiplexor process needs write access to `muxname/`, as it is the only thing expected to create files there.

All created display buffer files have permissions rw-r-----. All created input FIFO files have permissions rw--w----. All display buffer files and the input FIFO file have their group IDs explicitly set to the effective GID of the multiplexor process. The multiplexor process itself has owner access to these files, and their owner ID is the effective UID of the multiplexor process.

Usually `muxname/` will be set-group-ID to a group different to the effective group ID of the multiplexor process. Changing the groups of `muxname/input`, `muxname/display` to the effective GID of the multiplexor process thus distinguishes group access to those files in particular, allowing one to add ordinary users to the effective GID of the multiplexor process in order to give them direct realizer access to the multiplex terminal without (thereby) granting them (group) access to anything else in `muxname/input`.

Truncating the display buffer file at (non-abend) termination ensures that (absent system backups, log-structured filesystems, and low-level data recovery) old terminal display content cannot be read out of a display buffer. For best results, place these files on a temporary filesystem, set whatever options the temporary filesystem has (if any) for erasing backing storage at unmount, and exclude the temporary filesystem from backups.

## Author

Jonathan de Boyne Pollard