Automic Workload Automation

Expand all | Collapse all

Verify Agent setup

Jump to Best Answer
  • 1.  Verify Agent setup

    Posted 10-17-2019 02:53 PM

    I have inherited an Automic environment that I believe is not set up corrrectly:

    The client servers are Oracle Linux/RedHat linux. On each server there is an application running as a defined user, ie, wm, siadmin, ifwadmin, etc.

    The current setup, all automic related files are under /opt/automic. The userid for that server's application owns all directories and files under /opt/automic. For some reason, the automic ServiceManager and Agent is being started by a configuration manager product called CFEngine. I was told that was the only way they could get this setup to work because the effective ID was always root while the real ID was the application ID, or vice-versa. So, they configured CFEngine to fork a shell under the application ID and then fork another shell to start the ServiceManager and Agent.

    I have been advised to change all ownership to root:root, run the processes as root, and make sure any user running jobs has r/w/x to the Agent's temp directory. This obviously will work as root can do whatever it wants, but is that setup exploitable? Is there any way a user can execute a script to do nefarious things, or run a job that does something like reboot the server, delete OS files, change root password etc?

  • 2.  RE: Verify Agent setup

    Posted 10-17-2019 05:47 PM
    Edited by Spencer Cockrell 10-17-2019 05:48 PM
    Hi Brett,

    Hopefully I can help answer some of this, though perhaps not as in-depth as you need. The Agent running as root should be, generally, the requested/recommended configuration from Automic/Broadcom:

    The agent for UNIX operating systems can be installed to either run as a privileged or an unprivileged process. It is recommended to install it as a privileged process because only in this mode, the agent can operate with full capabilities.

    There are two methods to start the agent with root privileges:

    1. Start the agent directly under the user root.

    2. Define root as owner, assign the group where the start user has to be a member of, set the execute bit for the group and set the SetUID (s-bit) for the agent file owner.


      • chown root ucxjlx6
      • chgrp admin ucxjlx6
      • chmod 4550

    This shouldn't allow the jobs themselves to run as root, however, unless you specify the root user/pw in a login object - the user in the Login Object is the user that should be executing the commands on the server the Agent resides on (generally one with much less permission/access than root).

    In other words, as long as your user permissions are secure I don't think this should be a problem. They'll have whatever access they normally have when logging in with that user via login object/job in Automic.

    [Sr. Systems Engineer]

  • 3.  RE: Verify Agent setup

    Posted 10-18-2019 04:18 AM
    Agent has to run as root, in order to be able to substitute user (su on UNIX) using credentials from the LOGIN object.
    For this reason, you have to check the configuration of agent(s) on UNIX/Windows and Client (Automic):

    WINDOWS - INI file:
    ; logon: The settings for the execution of jobs / file transfers.
    ; See: Description of the settings ANONYMOUS_FT and ANONYMOUS_JOB in the variable UC_HOSTCHAR_DEFAULT.
    ; 0 - Jobs and/or file transfers and/or FileSystem Events start under the agent's OS user. The login data that is available in the Login object is not checked.
    ; 1 - The login data that is stored in the Login object is used.
    UNIX - INI file:

    ; login_Check: Password check.
    ; Note that the agent must have root rights as otherwise, login_check=yes does not work. Use login_check=no and ANONYMOUS_JOB=yes in this case. See also UC_HOSTCHAR_DEFAULT.
    ; yes - login credentials are checked
    ; no - login credentials are not checked


  • 4.  RE: Verify Agent setup
    Best Answer

    Posted 10-21-2019 03:29 AM

    Hi Brett,

    there is also another hurdle before jobs can be executed as root users. The [USERID] section in the INI file of the agent specifies which Unix users may or may not start jobs. The following should be the default (I did not check it with a current version):


    This means that the agent must not execute anything via root.

    As a result, a malicious user must have write access to the agent's INI file and restart the agent in addition to the ability to create or change a login object.

    Best regards,

    Automation Evangelist
    Fiducia & GAD IT AG
    Mitglied des deutschsprachigen Automic-Anwendervereins FOKUS e.V.
    Member of the German speaking Automic user association FOKUS e.V.