kbdload(1M) kbdload(1M)
kbdload - load or link kbd tables
kbdload [-p] filename
kbdload -u table
kbdload -l string
kbdload -L string
kbdload -e string
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
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 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 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 and -l options are used for making composite tables on the fly.
The -L option, if executed by the super-user, causes the composite to be
made publicly available; it is otherwise private and equivalent to -l.
The string argument is constructed in the same manner 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.
Page 1
kbdload(1M) kbdload(1M)
Security Issues [Toc] [Back]
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.) 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 super-user. Paths to
public tables are scrutinized for legitimacy. The kbdload command
refuses to work as a set-uid program.
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 message is
printed indicating the error.
/usr/lib/kbd - directory containing system standard map files.
kbdcomp(1M), kbdset(1), alp(7), kbd(7)
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 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.
PPPPaaaaggggeeee 2222 [ Back ]
|
