kbdload(1M)

kbdload -- load or link kbd tables

Synopsis

kbdload [-p] filename
kbdload -u table
kbdload -l string
kbdload -L string
kbdload -e string

Description

Tables included in file are loaded into the kbd STREAMS module that must already have been pushed into the standard input stream. (In this context loaded means copied from a disk file into main memory within the operating system.) This program is intended both to provide for loading and linking of both shared or public tables and private tables implementing user-specific functionality. New users should refer to kbdcomp(1M) and kbd(7) for a general description of the module's capabilities.

Files are searched for only by the name specified on the command line; no search path is implied. Tables loaded by a privileged user with the -p option from an absolute path beginning at /usr/lib/kbd are made publicly available and permanently resident. Otherwise the loaded tables are available only to the caller, and are automatically unloaded when the kbd module is popped from the stream.

The -u option can be used to unload private tables and by a privileged user to remove public tables. Tables may be unloaded only if they are not currently in use. (Tables that are members of composite tables always have non-zero reference counts since they are ``used'' in the composite; all composites that refer to them must be unloaded first.)

The -L and -l options are used for making composite tables on the fly. The -L option, when executed by a privileged user causes the composite to be made publicly available; otherwise, it is private and equivalent to -l. The string argument is constructed in the same way as the link statement (see kbdcomp(1M)) in the compiler. If any component of the intended composite is not presently loaded in memory or if a component of a public table is not also public, an error message is printed and the linkage fails. More than one composite may be created in a single invocation by using either option sequentially.

The -e option with a string argument causes kbdload to declare to the kbd module a subroutine called string, which is assumed to be a subroutine managed by and registered with the alp module (see alp(7)). These ``external'' subroutines may be used exactly as any other loaded table; they may participate as members of composite tables, and so on.

Security issues

Allowing users other than a privileged user to load public tables is a security risk and is thus disallowed. (In general, any manipulation of a module instance by a user who is neither a privileged user nor the user who originally pushed it is disallowed.) The library directory and all files contained in it should be protected by being unwritable. Administrators are encouraged to remember that the kbd system can be used to arbitrarily re-map the entire keyboard of a terminal, as well as the entire output stream; thus in extremely hostile environments, it might be prudent to remove execution permissions from kbdload for non-administrative users (for example, setting the owner to bin or root and giving it a mode of 0500).

The kbdload command checks to insure that the real uid of the invoker is the same as the owner of both standard input and standard output files, unless the real uid of the invoking user is the privileged user. Paths to public tables are scrutinized for legitimacy. The kbdload command refuses to work as a setuid program.

Files

/usr/lib/kbd: directory containing system standard map files.

Diagnostics

Exit status is 0 if all tables can be loaded and all operations succeeded. If there is an I/O error (for example, attempting to load a table with the same name as one already loaded and accessible to the caller) or failure to load a table, exit status is 1 and a message is printed showing the error.

References

alp(7), kbd(7), kbdcomp(1M), kbdset(1)

Notices

Composite tables may be unloaded while they are actually in use without affecting current users. New users may no longer attach to the tables, since composite tables are copied and expanded when they are attached. This is done to keep state information related to the attaching user. The original composite always has a zero reference count, and is never itself attached. This is an anomaly; the effect on the user is that a composite table may be attached and functional, yet not appear in the output of a kbdset(1) query.