version 1.1, 2007/01/12 01:42:16
|
version 1.1.2.4, 2007/01/17 18:48:55
|
|
|
|
################################################################################ |
|
## |
|
## CIM Server Policy Configuration File |
|
## ==================================== |
|
## |
|
## This file defines policy rules that restrict the execution of out-of-process |
|
## provider modules (only applicable when the privilege separation feature is |
|
## enabled). Each line defines a single rule and has the following format. |
|
## |
|
## MODULENAME:USERNAME |
|
## |
|
## MODULENAME is the name of a provider module (derived from the |
|
## PG_ProviderModule.Name property of some instance). |
|
## |
|
## USERNAME is one of the following. |
|
## |
|
## 1. The name of a valid system user, indicating that the provider module |
|
## may run as that user. This field is derived from the |
|
## PG_ProviderModule.DesignatedUserContext of some instance. |
|
## |
|
## 2. The string "${requestorUser}", indicating that the provider module |
|
## may run as the requesting client. |
|
## |
|
## 3. The string "${privilegedUser}", indicating that the provider module |
|
## may run as the privileged system user ("root" on Unix and Linux). |
|
## |
|
## 4. The string "${cimserverUser}", indicating that the provider module |
|
## may run as the same user as the CIM server. |
|
## |
|
## The value of USERNAME is determined by two properties set during provider |
|
## registration. |
|
## |
|
## PG_ProviderModule.UserContext |
|
## PG_ProviderModule.DesignatedUserContext |
|
## |
|
## The table below shows how the policy rules (column 3) are derived from |
|
## these two fields (columns 1 and 2). These examples assume a provider |
|
# module named "Fan" and a user named "jwilliams". |
|
## |
|
## +----------------+-----------------------+-----------------------+ |
|
## | UserContext | DesignatedUserContext | MODULENAME:USERNAME | |
|
## +----------------+-----------------------+-----------------------+ |
|
## | 2 (DESIGNATED) | jwilliams | Fan:jwilliams | |
|
## +----------------+-----------------------+-----------------------+ |
|
## | 3 (REQUESTOR) | NULL | Fan:${requestorUser} | |
|
## +----------------+-----------------------+-----------------------+ |
|
## | 4 (PRIVILEGED) | NULL | Fan:${privilegedUser} | |
|
## +----------------+-----------------------+-----------------------+ |
|
## | 5 (CIMSERVER) | NULL | Fan:${cimserverUser} | |
|
## +----------------+-----------------------+-----------------------+ |
|
## |
|
## Either the modulename or the username field may contain an asterisk, |
|
## indicating that there is no restriction on that field. |
|
## |
|
## The most permissive policy configuration file would contain the |
|
## following rule: |
|
## |
|
## *:* |
|
## |
|
## This rule permits ANY provider module to run as ANY user. |
|
## |
|
## For obvious reasons, this file should only be writable by the |
|
## administrator. |
|
## |
|
################################################################################ |
|
ProcessModule:${privilegedUser} |
|
ProcessorProviderModule:${privilegedUser} |
|
IPProviderModule:${privilegedUser} |
|
ComputerSystemModule:${privilegedUser} |
|
OperatingSystemModule:${privilegedUser} |
|
OOPModuleFailureTestProviderModule:${requestorUser} |