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.
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.
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().
Note
In this online version of the book, the long underscore (__) in front of the function name is actually two underscore characters (_ _).
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.
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.
/* 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.