Node and Host Name Sizes on HP-UX: Using the Expanded Capabilities of HP-UX

• Rebuild all clients of the application library to use the expanded HP-UX node/host name

interfaces. This satisfies the rule that all programs comprising an application be built in the

same manner. The library and all clients are expanded node/host name clean.

• Do nothing. The library and clients support only the nonexpanded node and/or host name

interfaces. This prevents the library and its client programs from fully supporting systems on

which the administrator has set a long node and/or host name.

• Make some modest code changes so the library supports two versions of the interface. For

data structure interfaces, clients that need to also support long node/host names must be

changed to access the expanded version of the data. For function interfaces, two functions

can be defined. One supports the nonexpanded node and host names, the other supports

the expanded names. This can be accomplished by introducing a second function with a

different name. Alternatively, the two functions can have the same name by using the FLV

mechanism described in Appendix D, “FLV Concepts and Usage”.

Buffer Overflow and Other Subtle Issues

The system interfaces provided for applications to obtain the node and host names do not overflow

buffers (unless parameters to those interfaces are incorrectly provided). However, long node and host

names can cause buffer overflows in applications.

Consider a program module to which is passed an internal data structure containing a pointer to a

node or host name. Using the strcpy() function, this module attempts to make a copy of the name

into its local buffer created using some constant for the size. If that constant is less than what is

necessary to contain the name, the buffer will overflow. (Using strncpy() would have been better

to avoid overflow, but the example assumes some existing code.)

This module, and perhaps the compilation unit in which it resides, shows no obvious reference to

gethostname(), utsname.h, uname(), the utsname structure or to any of the symbolic

constants MAXHOSTNAMELEN, SYS_NMLN, SNLEN, orUTSLEN. So, the module is easy to miss

during source code investigations.

This illustrates an important point. Investigation of node and host name dependencies in source code

cannot stop at just the source files that have references to the operating system symbols in the

preceding paragraphs. It is important to follow the data path of any node or host name string

defined by the program. A full search must also be made of all references to these program-specific

data field names.

Node or Host Names as Program Input

A node or host name might be supplied to an application as input via command-line options or data

files. If the names are longer than the program was built to handle, the names might be truncated,

cause run-time error messages, or cause buffer overflows (such as, when strcpy() or related string-

manipulation functions are used without regard to the accepting buffer size).

This is similar to the issue described in the previous subsection. However, an additional problem is

that the entire application source code might not exhibit references to any of the node and/or host

name related symbols. Therefore, it might not be obvious that the names are used anywhere in the

application. It is important to investigate the operational specification of an application as well as

scan its source for the telltale symbol references.

Note that buffer overflows can create a security problem (especially in setuid programs).