secons Utility—Manage CA Access Control Shutdown on UNIX

Reference Guide › Utilities › secons Utility › secons Utility—Manage CA Access Control Shutdown on UNIX

secons Utility—Manage CA Access Control Shutdown on UNIX

Valid on UNIX

The secons utility shuts down CA Access Control and the associated daemons. You can also use this utility to find out which processes are still executing CA Access Control code.

Only users defined as ADMIN or OPERATOR can shut down CA Access Control. To shut down CA Access Control on remote computers, you must be defined as ADMIN or OPERATOR on those remote computers.

This command has the following format:

secons [-s [hosts | ghosts]] \

[-S [{selogrd | selogrcd | serevu}]] \
[-sc] [-scl] [-sk]

‑s [hosts | ghosts]

Shuts down the CA Access Control daemons on the defined, space-separated, list of remote hosts. If you do not specify any hosts, CA Access Control shuts down on the local host.

You can define a group of hosts by entering the name of a ghost record. If you use this option from a remote terminal, the utility requests password verification. You also need admin privileges on both the remote and local computers, and write permission to the local computer on the remote host database.

‑S [{selogrd | selogrcd | serevu}]

If you do not define a daemon, terminates the CA Access Control daemons and attempts to terminate active daemons selogrd, selogrcd and serevu. If the selogrd, selogrcd, or serevu tokens in the [daemons] section of seos.ini file are set to yes, sends the termination request to the running CA Access Control main daemon or sends the termination signal to the specified daemon if CA Access Control is already down.

If you define a daemon, secons does not terminate the CA Access Control daemons. If the appropriate token in the [daemons] section of seos.ini file is set to yes, it sends the termination request to the running CA Access Control main daemon or it sends the termination signal to that daemon if CA Access Control is down.

-sc[l]

Displays processes that are still executing CA Access Control code.

You cannot unload CA Access Control if an application, which is loaded on top of CA Access Control, has an open system call (syscall) that is hooked by CA Access Control. Once you know which processes are still executing CA Access Control code, you can shut down these processes and unload the CA Access Control kernel module. You can then use UNIX exits to automatically shut down these processes before unloading the kernel and then restart them after the kernel unloaded.

The -sc output displays as a two-column table with the system call number in the first column, and the process identifier in the second column.

The -scl option also displays parent process ID (PPID), UID, time, and program name information for the processes that are still executing CA Access Control code. The time information lets you find out how long the process has CA Access Control hooked. If the time is relatively short, the hook is likely to be a temporary one.

You can also run this while CA Access Control is running to help you predict what may cause unload issues in advance. However, in some cases, such as the accept command, CA Access Control code removes the hook during unload. This means that some of the active hooks you see while CA Access Control is running may not actually affect unloading.

Note: By default, CA Access Control monitors system calls intercepted by CA Access Control. You must set the syscall_monitor token in the seos.ini file to 0 (disabled) if you do not want CA Access Control to monitor system calls.

-sk

Shuts down all CA Access Control daemons and prepares the CA Access Control kernel extension to be unloaded.

Example: Shut Down CA Access Control

To shut down the CA Access Control daemon, enter:
```
secons ‑s
```
To shut down the CA Access Control daemon on remote hosts HOST1 and HOST2, enter:
```
secons ‑s HOST1 HOST2
```

Example: Display Information for Processes that are Still Executing CA Access Control Code

To display basic information on processes that are still executing CA Access Control code:

secons ‑sc

The output you receive looks similar to the following:

CA Access Control secons vX.X.X.xxx - Console utility
Copyright (c) YYYY CA. All rights reserved.
Active system calls:

syscall    5 - PID:  27477

To display more information on processes that are still executing CA Access Control code:
```
secons ‑scl
```
The output you receive looks similar to the following:
```
CA Access Control secons vX.X.X.xxx - Console utility
Copyright (c) YYYY CA. All rights reserved.
Active system calls:

-Syscall  102 - PID:   2105  PPID:      1 UID:      0 TIME:    4d-4h PROGRAM NAME: /usr/sbin/vsftpd
 Syscall    5 - PID:  24269  PPID:   4289 UID:      0 TIME:   2d-21h PROGRAM NAME: /bin/bash
```
A dash (-) at the beginning of the output line means that CA Access Control assesses that this hook is not likely to cause you issues when unloading. When you use this command, CA Access Control also adds lines to the audit log that records whether the unloading CA Access Control is likely to succeed. For example, the following audit record is created when you run secons -scl and there is at least one blocking system call that is likely to prevent CA Access Control from unloading:
```
10 Nov 2008 05:47:22 F CHECK        root       Scan      339  0 SEOS_syscall     unload
```