This is a generic document illustrating some scenarios where the implementation of AC can stress the system and degrade performance as a result. The scope of this document is not to recommend any specific set of AC rules or commands, but rather to provide some generic ideas that can be taken into consideration when the implementation of AC is in its planning stages, or being tested in a non-production environment.
There are several factors that can have a bearing on how resources are utilized once AC is active on a system, nevertheless it is normally the case that the design and implementation of the AC rule set is one of the key factors.
For example; given a standard installation of AC where no seos.ini tokens have been modified, the AC administrator implements a set of FILE rules to protect certain resources some of which are of the type:
/usr/bin/* /usr/lib/* or my_fileset/*
A multiple set of rules like these where wildcards are used, could have a negative impact on the system once AC is active. This although sometimes presented as a 'problem' caused by AC, is by no means so.
Each time one of the files inside one of the directories protected by a rule with a wildcard is accessed, a request to seosd for an authorization check will be generated. On a heavily utilized system with large number of users simultaneously accessing resources, performance can rapidly degrade as a result of seosd being 'flooded' with authorization check requests, which will be queued until all of them have been processed.
There are several ways of addressing a scenario like this, one of which is to carefully review the rule set and be as granular as possible avoiding the unnecessary use of generic rules.
However where the use generic rules is necessary, further analysis of the rule set should be carried out in order to determine whether to implement some of the caching mechanisms available, that can help to avoid stressing the system once the AC rules are enforced.
For instance; if a seosd.trace shows that a particular rule set is constantly being enforced as a result of repeated access to the same set of files, GAC could be implemented so that only the first access to a designated resource is checked but not subsequent ones.
Another source of potential performance degradation, could be constant calls to fork() and its subsequent interception by AC, typically generated by shell scripts but also by other applications that may be running on the system. A way to tackle such scenario, could be by setting the synchronize_fork token in the seos.ini file to 1, (by default set to 2 on most platforms)
The meaning of the values for this token can be seen below:
0 do not report forks to main daemon (to avoid an answer delay)
1 report forks from parent ; parent reports without synchronization
2 report forks from child ; parent reports with synchronization
As documented in the seos.ini file, setting the synchronize_fork token to 0 is deprecated as it can have the undesired side effect of AC not being able to track processes back to their original owner.
Another example, is where a particular program is generating a large number of syscalls intercepted by AC, in such cases, the SPECIALPGM class can be implemented allowing designated programs to have their access to system resources bypassed by seosd.
On Solaris systems only, bypassing access to the /proc file system can help to avoid performance degradation and can be achieved by setting the proc_bypass token in the seos.ini file to 513 in Solaris 8 and Solaris 9 and to 1 in Solaris10 (For Solaris 10, only 0 or 1 are valid values)
For further information on the topics discussed in this document, please consult the following AC documentation:
- Administration guide, section entitled 'Improving Performance'
- Reference guide, section entitled 'SPECIALPGM class'
- Utilities guide, section entitled 'Trace Messages'
Note: specific page numbers for the guides above are not included as although the topics can be found under the named sections in both documentation sets for R8.0SP1 and R12.*, the page numbers are not the same.