7.1.3.Security
Due to the Unix security model certain kernel calls can only be used when the process is run by root or under the permission of root. One of these function calls is needed for the PingWatchDog protocol, thereby forcing you to run the request broker as root. This can be accomplished in two ways:
-
The user logs in as root and then fires up the request broker.
-
The request broker is flagged to run under root privileges and the user can start it up from other accounts.
The consequences of 1 are that the user(s) who need to startup the broker need to have knowledge of the root password, which is not advisable for system managers to give to ordinary users.
Therefore we have built a solution whereby the broker can be flagged as running under root privileges without the user(s) needing to know the root password. The system manager executing the following commands accomplishes this:
cd openlink/bin ./security -s
This will place the broker into a special security state that has the following impact:
-
The permissions of the oplrqb program are changed so it takes on the identity of "root" when started up.
-
The broker now knows the position of the oplrqb.ini file and will not accept certain startup flags so it cannot be tricked to read in another oplrqb.ini file from the command line.
-
The oplrqb.ini file can now only be written to by the "root" account, other accounts will only be able to read this file.
If a user now starts the broker the StartupBy clause within the [Security] section of the broker is checked to see whether the user is allowed to startup the broker (same for shutdown).
This accomplishes the wish of many system administrators that the broker process can be started up as root, without widespread knowledge of the root password.
As stated in item 3 above the "oplrqb.ini" file can now only be written to by the "root" account. This means that ordinary users cannot modify this file, which often seems like an unpleasant side effect. To overcome this some system administrators are temped to modify the mode of the oplrqb.ini file, thereby opening up to security risks. This should be avoided, the IncludeRuleBook parameter inside the Security sections should be used instead to divide the rulebook in to parts for others to manage for themselves. The system administrator can split up the rulebook into different files which than can be included from the master oplrqb.ini file. This makes specific sections available to normal users, but allowing the system administrator to decide which sections can/cannot be overruled by normal users. The included rulebooks cannot overrule any section within the oplrqb.ini file. This is a very powerful way of dealing with high security installations within large companies.