CA XCOM xcomtcp processes on Linux/Unix running as root user

Products

• XCOM Data Transport
• XCOM Data Transport - Linux PC

Issue/Introduction

Our xcom.glb file has default settings for XCOM_USERID and XCOM_PASSWORD

XCOM_USERID=xcom
#   This parameter assigns the default value of the USERID which
#   is used if no USERID is provided by the remote system.
#   WARNING! Setting this as well as the XCOM_PASSWORD field to blank (null)
#   disables security and allows incoming transfers to run as root.

XCOM_PASSWORD=
#   This parameter assigns the default value of the PASSWORD which
#   is used if no PASSWORD is provided by the remote system.
#   WARNING! Setting this as well as the XCOM_USERID field to blank (null)
#   disables security and allows incoming transfers to run as root.

See online documentation:
XCOM_USERID
XCOM_PASSWORD

However, when remotely initiated XCOM transfers are executed, the ps command shows that xcomtcp processes always run as root. 
    root 15859958  5570752   1 07:39:00      -  0:00 xcomtcp REMOTE 0
Based on the above xcom.glb comments is that a security concern or expected behaviour?

Environment

Release : 11.6
Component : CA XCOM DATA TRANSPORT FOR LINUX, CA XCOM DATA TRANSPORT FOR AIX/UNIX

Resolution

With respect to the users associated with a Linux/Unix process there are two different properties, the Real User ID (RUID) and the Effective User ID (EUID).
In the case of the xcomtcp, xcomqm, and xcomd processes, they have the sticky bit set and their Real User ID will be "root" most of the time.
For an xcomtcp transfer process the Effective User ID, which determines the privileges of the process, will initially be root but is then set to the USERID specified in the remote transfer configuration.
NOTE: The xcomtcp owner cannot be changed to a non-root user, otherwise it will not be able to validate the user credentials, and subsequently, it fails to start properly as it lacks the ability to set the Effective User ID to the xcomtcp process. 
To see how the Effective User ID changes during the process lifecycle a script like the following, which runs the ps command continuously in a while loop, can be started before the remote transfer is initiated to redirect/append the ps output to a file:
===
while true
do
        echo "Press CTRL+C to stop the script execution"
        ps -eo ruid,uid,ruser,user,pid,ppid=parent,args | grep xcomtcp | grep -v grep >> xcomtcp.out
done
===
NOTE: When using the default ps output format with command "ps -ef" the result on Linux and Unix may show a different User ID e.g. Red Hat Linux will show the Effective User ID, while AIX will show the Real User ID. Hence the above ps output format is used to show both User IDs.

If USERID=user1 is specified in the remote transfer configuration file, the xcomtcp.out file shows the following (column headers add for ease of understanding):
===
RUID UID RUSER USER PID      parent COMMAND
...
    0         0 root     root     228528   1760 xcomtcp REMOTE 0
    0         0 root     root     228528   1760 xcomtcp REMOTE 0
    0         0 root     root     228528   1760 xcomtcp REMOTE 0
    0         0 root     root     228528   1760 xcomtcp REMOTE 0
    0 54324 root   user1    228528   1760 xcomtcp REMOTE 0
    0 54324 root   user1    228528   1760 xcomtcp REMOTE 0
    0 54324 root   user1    228528   1760 xcomtcp REMOTE 0
...
===

The USERID sent will of course also be used for the actual file transfer authentication and the destination file will be owned by that USERID.

Per the comments in the xcom.glb file, the XCOM_USERID and XCOM_PASSWORD will only be used as default values if the remote transfer does not explicitly specify USERID and PASSWORD. The potential security risk referred to in the comments does not relate to the xcomtcp processes running as root because as explained above the USERID specified in the transfer becomes the Effective User ID of that process. Rather the potential security risk relates to when both XCOM_USERID and XCOM_PASSWORD are set to blank. In that case if a remote transfer does not specify a USERID there is no security check run for the file transfer (there is no USERID to check), so the xcomtcp process will have an Effective User ID of root and also the destination file will be owned by root.

So in summary, as long as both XCOM_USERID and XCOM_PASSWORD are not set to blank, there is no concern about xcomtcp processes running as root because their Effective User ID will either be set to the USERID specified by the remote transfer configuration or set to XCOM_USERID if a USERID has not been specified.