XCOM for Linux successful transfers end with return code 3 (AWS EC2 Cloud)

Products

• XCOM Data Transport
• XCOM Data Transport - Linux PC

Issue/Introduction

Environment: XCOM 12.0 (latest cumulative XCLX86_XCOMPATCH_r12025032_64.bin) on Amazon AWS EC2 Red Hat 8.10 image. 
The xcomtcp transfer ends with a return code 3 when check using command "echo $?" i.e.

$ xcomtcp -c1 -f ./loop.cnf
2025/06/02 19:50:56 TID=000028 [/home/xcom_user/xcom_tests/file1 --> /home/xcom_user/xcom_tests/file2 at 127.0.0.1]
    XCOMU0029I Locally initiated transfer started.

2025/06/02 19:50:56 TID=000028
    XCOMU0011I Transfer ended; 1 blocks (6 bytes) transmitted in 0 seconds (6 bytes/second)

$ echo $?
3

This is documented in this article: XCOM for Linux/UNIX successful transfers end with return code 3
However the required sticky bit file permissions are already set by the install.
# ls -al /opt/CA/XCOM/bin/xcomtcp
-r-sr-sr-x. 1 root xcomadm 3764811 Apr 23 21:29 /opt/CA/XCOM/bin/xcomtcp

After running a transfer with XTRACE=10 this is what is shown:
*****
 security.c 2159: Xsetuid: ruid=######, euid=######, rgid=#######, egid=######, 
 security.c 2176: Xsetuid: Not running as euid root, skipping initgroups() call
...

 sdu.c 1445: Xrename: rename() returned -1, errno=2
 sdu.c 1528: Xrename: Entering copy logic
 sdu.c 1530: Xrename: open files </tmp/ipJ
288856.it> and </tmp/077153.it>
 
 sdu.c 1596: Xrename: open() of /tmp/ipJ
288856.it failed, errno=2
 xfree: (34) freeing 0x14ac4a0
 dummy debug_leak_delete for 0x14ac4a0
 End of LocalRequest, RC=0
 driver.c 1177: About to call XsetSysPriv() from driver.c #1
 security.c 2355: XsetSysPriv: seteuid(0) returned -1.
 security.c 2359: XsetSysPriv: errno=1:Operation not permitted.
 driver.c 1180: XsetSysPriv() failed
 FreeAllParmblocks:
...
*****

If run the transfer as root user, the return code is 0 for a successful transfer and 3 for a failure, as would be expected. So it is definitely a permissions related problem.

Environment

XCOM™ Data Transport® for UNIX/Linux PC
AWS EC2 Cloud

Resolution

Trace collected by Support with return code 0 shows:
*****
 security.c 2159: Xsetuid: ruid=######, euid=######, rgid=#######, egid=######, 
 security.c 2171: Successfully set group list via initgroups for <xcom_user>
...
 driver.c 1177: About to call XsetSysPriv() from driver.c #1
 security.c 2355: XsetSysPriv: seteuid(0) returned 0.
 security.c 2367: XsetSysPriv: getgrnam("xcomadm") returned 0x7f79d486f0c0.
 security.c 2379: XsetSysPriv: setegid(1004) returned 0.
 security.c 2387: XsetSysPriv: successful
*****

Provided trace with return code 3 shows:
*****
 security.c 2159: Xsetuid: ruid=######, euid=######, rgid=#######, egid=######, 
 security.c 2176: Xsetuid: Not running as euid root, skipping initgroups() call
...
 driver.c 1177: About to call XsetSysPriv() from driver.c #1
 security.c 2355: XsetSysPriv: seteuid(0) returned -1.
 security.c 2359: XsetSysPriv: errno=1:Operation not permitted.
 driver.c 1180: XsetSysPriv() failed
*****

For the message "XsetSysPriv: seteuid(0) returned -1", the manual page for seteuid indicates the error -1 can occur when a process is not privileged i.e. it does not have the CAP_SETUID capability in its user namespace. It would be the same for for setegid() returning a value of -1 if a process does not have the CAP_SETGID capability in its user namespace.
It seems that AWS EC2 is providing different Red Hat images that remove or disable one or both of these capabilities in a user namespace. 

These settings were required to resolve the problem i.e. the transfer resulted in a return code of 0:

1. Use this command to enable setuid and setgid capabilities for the xcomtcp executable file:
   setcap 'cap_setuid+ep cap_setgid+ep' /opt/CA/XCOM/bin/xcomtcp
   
   
2. Remount /tmp/ and /opt/ without "nosuid"
   
   
3. Relabel the security context of the XCOM files from "unconfined_u:object_r:unlabeled_t:s0" to "system_u:object_r:usr_t:s0" with command:
   chcon -R system_u:object_r:usr_t:s0 /opt/CA/XCOM/