Best Practices for Deploying HP-UX Secure Resource Partitions (SRP) for SAP Whitepaper

8
Known limitations
Saposcol
SAP delivers its own data collector, saposcol, to provide OS information (e.g. for CCMS). The data
collector may run only once on a system. It addresses a shared memory segment with a predefined
shared memory key that cannot be changed. If saposcol is started by an SAP instance in one
compartment, other SAP instances cannot connect to saposcol due to the SRP compartment rules. They
also cannot start their own saposcol because the shared memory segment is already occupied.
To avoid this problem, saposcol can be started in one of two ways: 1) in the INIT compartment as
root user without further restrictions, or 2) in a separate compartment created only for saposcol.
Which solution is used depends on the desired level of security.
If saposcol will be run in a secure environment, it is recommended to create a separate SRP
compartment dedicated for saposcol with full access to saposcol and allowing IPC communication but
deny execution access for all other compartments. With this approach, data collected by saposcol
can be read by all SRP compartments but the process cannot be stopped by any of them.
The known issue with this approach is that the data shown by saposcol is valid not only for the SRP
compartment requesting the information but for the whole system as well. For example, the CPU
utilization for the whole system is displayed, not just the CPU utilization for the compartment
requesting the information.
Display problem in transaction ST06
The Collector status display in SAP transaction ST06 also has limitations. The information is not read
from the shared memory, but from the output of calling saposcol. Calling saposcol is prohibited in the
default examples so that saposcol cannot be stopped accidentally by any SAP system.