At a minimum, limit non-trusted user accounts to object authority of use to the Universal Broker product library, UNVPRD510; the product temporary library, UNVTMP510; the command reference library, UNVCMDREF; the universal spool library, UNVSPL510; and all objects within these libraries.
 
For maximum security, only trusted accounts (administrators and the UNVUBR510 profile) should have management, existence, alter, add, update, or delete authority to these objects. As a reminder, the system value QCRTAUT controls public access authority to created objects unless overridden by specific commands.
 
User profiles that use Stonebranch products require *CHANGE authority to the UNVTMP510 library.

All files that the Broker creates or updates are located in either $SYSTEM.UNVLOG or $SYSTEM.UNVTRACE. The Broker does not need write access to its installation subvolume.

All files that the Broker creates or updates are located in the /var/opt/universal directory. This means that the Broker does not need write access to its installation directory or subdirectories.
 
Universal Broker requires full control (read, write, remove, and add) of the /var/opt/universal directory and its subdirectories. The Broker creates spool files, trace files, and log files in this directory. Only the account used to execute the Broker requires full access to this directory.
 
The Broker configuration options can be changed to use directories other then /var/opt/universal. If this is the case, the same permissions must be set up for these specified directories.

Universal Broker requires write access to its primary install directory (that is, .\Universal\UBroker), which serves as its default trace file location.
 
The Broker requires full control over the database directory (that is, .\Universal\spool), along with all subdirectories and files under that location.
 
When the Broker executes as a console application with its message destination set to logfile, the Broker requires full control over the .\Universal\Broker\log directory and all .log files within it. The Universal Broker Windows service always writes its message to the Windows event log, which means that it requires no write access to a log directory or any other of its installation subdirectories and files.

Universal Broker requires update access to its database files, which exist as HFS- or zFS-allocated datasets mounted on the z/OS Unix System Services (z/OS USS) file system. The Broker accesses HFS-allocated datasets using the UNVDB and UNVSPOOL ddnames in its STC JCL. The Broker accesses zFS-allocated datasets via its UNIX_DB_DATA_SET and UNIX_SPOOL_DATA_SET configuration options.

Although you can edit Universal Agent configuration files with any text editor (for example, Notepad), we recommend using the Universal Configuration Manager Control Panel application set configuration options.
 
The Universal Configuration Manager provides a graphical interface and context-sensitive help, and helps protect the integrity of the configuration file by validating all changes to configuration option values. It also directs the Broker to refresh its cache of Universal Agent component configuration settings, making it unnecessary to issue a separate configuration REFRESH request via the Universal Control utility.

Although you can edit the UACL file with any text editor (for example, Notepad), we recommend that you maintain UACL entries using the Universal Configuration Manager Control Panel application. The Universal Configuration Manager sends a configuration refresh request to the Universal Broker. Updated values take effect immediately, making it unnecessary to recycle the Broker to apply UACL changes.

Universal Broker for IBM i runs with the UNVUBR510 user profile, which is created at product installation time. Any component started by Universal Broker inherits this user profile.
 
By default, the UNVUBR510 user profile has *ALLOBJ, *JOBCTL, and *SPLCTL authority. Unless the user profile is modified as described in the following section, *ALLOBJ authority is required for a component to switch its user profiles based on the request it is servicing. *JOBCTL authority is required for internal control and should not be removed. The UNVUBR510 user profile requires *SPLCTL authority to provide Universal Submit Job job logs in specific, limited situations.
 
Any other product or user should not use the UNVUBR510 user profile. By default, users cannot access the system with the UNVUBR510 profile.

Removing *ALLOBJ Authority from UNVUBR510 User Profile

Given the extensive authority allowed by *ALLOBJ special authority, it is desirable to avoid its use when possible. As of PTF 0UC0126 for V1R2M1, it is possible to remove *ALLOBJ special authority from the UNVUBR510 user profile. However, by removing *ALLOBJ from the UNVUBR510 user profile, the administrative complexity is increased.
 
The following steps are required to use Universal Command with *ALLOBJ special authority removed from the UNVUBR510 user profile.
 
1. If the following objects do not have *USE Public Authority, the UNVUBR510 user profile must be given *USE authority:

• QSYS/QSYGETPH
• QSYS/QWTSETP
• QSYS/QWCRJBST
• QSYS/QUSRMBRD

This can be accomplished with the following command:

===> EDTOBJAUT OBJ(QSYS/object_name) OBJTYPE(*PGM)

 
From the resulting screen, use F6 to add user UNVUBR510 and give it *USE authority.
 
2. UNVUBR510 user profile must be given *USE authority to the user profile objects of all user profiles that will be using the universal command server on the IBM i.
 
This can be accomplished with the following command:

===> EDTOBJAUT OBJ(QSYS/user_profile_name) OBJTYPE(*USRPRF)

 
From the resulting screen, use F6 to add user UNVUBR510 and give it *USE authority.
 
3. Use the following command to remove the UNVUBR510 user profile *ALLOBJ authority:

===> CHGUSRPRF USRPRF(UNVUBR510) SPCAUT(*JOBCTL *SPLCTL)

Removing *SPLCTL Authority from UNVUBR510 User Profile

Use the following command to remove the UNVUBR510 user profile *SPLCTL authority:

===> CHGUSRPRF USRPRF(UNVUBR510) SPCAUT(*JOBCTL *ALLOBJ)

Removing *ALLOBJ and *SPLCTL Authorities from UNVUBR510 User Profile

Use the following command to remove all special authority from the UNVUBR510 user profile:

===> CHGUSRPRF USRPRF(UNVUBR510) SPCAUT(*JOBCTL)

 
(Please refer to the previous two sections for additional information.)

Universal Broker itself does not require super.super privileges. For example, Universal Command (UCMD) Server may require super.super authority. Since the component inherits its user ID from the Broker, either the Broker must be running as super.super or the UCMD Server program must be owned by super.super and ProgID must be set for the server program file.
 
If the Broker is started as a daemon at system startup time, it is started with a user ID of super.super. The Broker and all its components will then have sufficient authority.

Although Universal Broker itself does not require superuser privileges, some Universal Agent server components (for example, UCMD Server and UEM Server) may require superuser authority to switch execution context to another user account, initialize group membership, or perform other privileged operations.
 
Since the component inherits its user ID from Universal Broker, one of the following is required:

• Universal Broker must execute as root.

• root must own the Universal Agent Server application file (for example, ucmsrv or uemsrv), and the Universal Agent Server application file must have its "set user ID on execution" bit (setuid on exec) set (for example, chmod u+s ucmsrv).
   
  By default, the Universal Broker is owned and started with a user ID of ubroker. root will own the server components that need superuser authority and these components will have their "set user ID on execution" bit set.
   

  Note

  Universal Agent server components typically only invoke the privileged operations mentioned above when that component is configured to run with security enabled (that is, its security configuration option is set to a value other than none). When security is disabled in a Universal Agent server component's configuration, that component may not attempt to invoke any privileged operations, but relies completely upon the security context it inherits from the Broker.

The Universal Broker Windows service can be configured to execute with the Local System account or with a specially-configured Administrative account (see Windows Service).