This appendix describes the naming convention for routines (added by
developers) that must be followed to stay in compliance with ANSI C routine
naming rules.
E.1 Overview of the Symbol Preemption Problem
Overriding
the symbols used by the SIA routines in
libc
is not as
simple as providing routines named the same as the SIA routines (such as,
siad_ses_init()) in a library loaded before
libc.a.
This is because of the ANSI C convention for
libc
routine
names and the symbols that must be reserved to the user.
A conflict exists
between the requirements of ANSI C and the expectations of the application
developers regarding what entry points can exist in the
libc.a
and
libc.so
libraries.
The ANSI C standard lists the symbols
allowed, and the only other symbols that are valid must be of the "reserved-to-vendor"
form.
That is, they must start with two underscores, or one underscore and
a capital letter.
This set of symbols is limited, and does not meet the expectations
of the general user community.
E.2 The Tru64 UNIX Solution
To satisfy both ANSI C and developer expectations, Tru64 UNIX
uses "strong" and "weak" symbols to provide the additional
names.
If a routine such as
bcopy()
is not allowed by
ANSI C, it has a weak symbol named
bcopy()
and a strong
symbol named
_ _bcopy().
The weak symbol can be preempted by the user with no effect on the
bcopy()
routine within
libc, because the library
uses the strong symbols for these "namespace-protected" routines.
For the SIA
routines, this means that there is a weak symbol for
siad_ses_init
which is normally bound to the strong symbol
_ _siad_ses_init().
If other code already uses the symbol
siad_ses_init(), only the binding of the weak symbol is affected.
The SIA code in
libc
references the strong symbol
_ _siad_ses_init()
for its own uses.
Thus, to override the
default BASE security mechanism for single-user mode, it is necessary to provide
a replacement for the
_ _siad_ses_init()
routine.
For a library that is only dynamically loaded under the control of the
SIA routines and the
/etc/sia/matrix.conf
file, it is only
necessary to provide the
siad_ses_init()
form of the symbol
name.
If the dynamically loaded library is only used through the
matrix.conf
file, it is acceptable to provide both forms of symbols.
This simplifies the code, but is not safe if the library usage ever changes
to require that the library be linked against, not just dynamically loaded.
E.3 Replacing the Single-User Environment
Example E-1
shows the code to use if a security mechanism
library developer needs to replace the single-user environment as well as
provide a normal shared library for
matrix.conf.
Example E-1: Preempting Symbols in Single-User Mode
/* preempt libc.a symbols in single-user mode */ #ifdef SINGLE_USER # pragma weak siad_ses_init = _ _siad_ses_init # define siad_ses_init _ _siad_ses_init #endif #include <sia.h> #include <siad.h>
The single-user (static) library modules are then compiled as follows:
%cc -DSINGLE_USER ...
This keeps the shared library from interfering with the
libc.so
symbols, but allows the preemption of the
libc.a
symbols for the nonshared images used in single-user mode.
The nonshared
images are then built with the replacement mechanism library supplied to the
linker before
libc.a
as in the following example:
%cc -non_shared -o passwd passwd.o -ldemo_mech
The shared library is built in the normal fashion.