kbdload(1M) 04 Jun 1992 kbdload(1M)
NAME
kbdload - load or link kbd tables
SYNOPSIS
kbdload [-p] filename
kbdload -u table
kbdload [-p] -l string
kbdload -e string
DESCRIPTION
Tables included in the file filename are loaded into the kbd STREAMS
module, which 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 kbd module's capabilities.
Files are searched for only by the name given on the command line; no
search path is implied. Tables loaded by the super user with the -p
option are made publicly available and permanently resident, otherwise
the loaded tables are available only to the caller, and are automati-
cally unloaded when the kbd module is popped from the STREAM.
The -u option can be used to unload private tables, and by the super-
user to remove public tables. Tables may be unloaded only if they are
not currently in use. (Tables which are members of composite tables
always have non-zero reference counts since they are ``used'' in the
composite; all composites which refer to them must be unloaded first.)
The -l option is used for making composite tables on-the-fly. If given
with the -p option and executed by the super-user the composite is
made publicly available; it is otherwise private. The string argument
is constructed in the same manner as the compiler link statement [see
kbdcomp(1M)]. 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 the
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 sub-
routine 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, etc.
Security Issues
Allowing users other than the super-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 the super-user nor the
user who originally pushed it is disallowed.) Administrators are
Page 1 Reliant UNIX 5.44 6, 194
kbdload(1M) 04 Jun 1992 kbdload(1M)
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).
EXIT VALUES
Exit status is 0 if all tables could be loaded and/or all operations
succeeded. In the event of any 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 mes-
sage is printed indicating the error.
CAVEATS
Composite tables may be unloaded while they are actually in use
without affecting current users, though new users may no longer attach
to it. This is because composite tables are copied and expanded when
they are attached in order to keep state information related to the
attaching user. The ``original'' composite always has a zero refer-
ence count, and is never itself attached. This is not strictly a bug,
it's 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 query.
FILES
/usr/lib/kbd directory containing system standard map files
SEE ALSO
kbdset(1), kbdcomp(1M), alp(7), kbd(7).
Page 2 Reliant UNIX 5.44 6, 194