11 Configuring GGSCI Command Security

You can establish command security for Oracle GoldenGate to control which users have access to which Oracle GoldenGate functions.

Note:

The GGSCI program is only available in the Oracle GoldenGate CA.

For example, you can allow certain users to issue INFO and STATUS commands, while preventing their use of START and STOP commands. Security levels are defined by the operating system's user groups.

To implement security for Oracle GoldenGate commands, you create a CMDSEC file in the Oracle GoldenGate directory. Without this file, access to all Oracle GoldenGate commands is granted to all users.

Note:

The security of the GGSCI program is controlled by the security controls of the operating system.

Topics:

11.1 Setting Up Command Security

  1. Open a new ASCII text file.
  2. Referring to the following syntax and the example on , create one or more security rules for each command that you want to restrict, one rule per line. List the rules in order from the most specific (those with no wildcards) to the least specific. Security rules are processed from the top of the CMDSEC file downward. The first rule satisfied is the one that determines whether or not access is allowed.

    Separate each of the following components with spaces or tabs.

    command_name command_object OS_group OS_user {YES | NO}
    

    Where:

    • command_name is a GGSCI command name or a wildcard, for example START or STOP or *.

    • command_object is any GGSCI command object or a wildcard, for example EXTRACT or REPLICAT or MANAGER.

    • OS_group is the name of a Windows or UNIX user group. On a UNIX system, you can specify a numeric group ID instead of the group name. You can use a wildcard to specify all groups.

    • OS_user is the name of a Windows or UNIX user. On a UNIX system, you can specify a numeric user ID instead of the user name. You can use a wildcard to specify all users.

    • YES | NO specifies whether access to the command is granted or prohibited.

  3. Save the file as CMDSEC (using upper case letters on a UNIX system) in the Oracle GoldenGate home directory.

The following example illustrates the correct implementation of a CMDSEC file on a UNIX system.

Table 11-1 Sample CMDSEC File with Explanations

File Contents Explanation
#GG command security

Comment line

STATUS REPLICAT * Smith NO

STATUS REPLICAT is denied to user Smith.

STATUS * dpt1 * YES

Except for the preceding rule, all users in dpt1 are granted all STATUS commands.

START REPLICAT root * YES

START REPLICAT is granted to all members of the root group.

START REPLICAT * * NO

Except for the preceding rule, START REPLICAT is denied to all users.

* EXTRACT 200 * NO

All EXTRACT commands are denied to all groups with ID of 200.

* * root root YES

Grants the root user any command.

* * * * NO

Denies all commands to all users. This line covers security for any other users that were not explicitly granted or denied access by preceding rules. Without it, all commands would be granted to all users except for preceding explicit grants or denials.

The following incorrect example illustrates what to avoid when creating a CMDSEC file.

Table 11-2 Incorrect CMDSEC Entries

File Contents Description
STOP * dpt2 * NO

All STOP commands are denied to everyone in group dpt2.

STOP * * Chen YES

All STOP commands are granted to Chen.

The order of the entries in Table 11-2 causes a logical error. The first rule (line 1) denies all STOP commands to all members of group dpt2. The second rule (line 2) grants all STOP commands to user Chen. However, because Chen is a member of the dpt2 group, he has been denied access to all STOP commands by the second rule, even though he is supposed to have permission to issue them.

The proper way to configure this security rule is to set the user-specific rule before the more general rule(s). Thus, to correct the error, you would reverse the order of the two STOP rules.

11.2 Securing the CMDSEC File

The security of the GGSCI program and that of the CMDSEC file is controlled by the security controls of the operating system. Because the CMDSEC file is a source of security, it must be secured. You can grant read access as needed, but Oracle recommends denying write and delete access to everyone except for system administrators.