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 console-terminal-emulator(1). 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. It will create these if they do not exist.

It then enters a loop where it simultaneously:

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.)

The session switch event extension to the console-terminal-emulator(1) input protocol is

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