E Symbol Preemption for SIA Routines

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 Digital UNIX Solution

To satisfy both ANSI C and developer expectations, Digital 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.

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.