QMClient: illegal action code (10001)

[Kevin Powick]

I have OpenQM 3.4-8 running on macOS BigSur (11.1).  Actually, I recently upgraded to BigSur from Mojave, which I suspect is the cause of the problem.

The issue is that I can no longer connect to QM from my Windows applications that use the QMClient/API.

When I try to QMConnect(), it fails with QMError() returning the message: "illegal action code (10001)".  What does this mean?

I can find no further details on this error message, so I don't know if this is a permissions issue or something else.

I can connect to QM from Windows via a Telnet (port 4242) connection, so I know that the server is reachable.  In case QMClient port 4243 is blocked, I have tried disabling the macOS firewall to no avail.

The only entries I see in  /qmsys/errlog related to the failed logon attempts are similar to the following:

17 Jan 21 12:18:20 User 9 (pid 5454, admin, QMSYS): Connection to client lost. IP addr 192.168.2.38

Any insights appreciated.

--

Kevin Powick

[Martin Phillips]

Kevin,

 

This error occurs if the client side of a QMClient connection sends an action request that is not compatible with the current state of the connection. In this specific case it appears to be attempting to login when already logged in.

 

The most common cause of this sort of error is for a multi-threaded client to attempt to initiate actions on the same QMClient session from two threads simultaneously, however, the wording of your email suggests that this is happening all the time rather than occasionally which makes this unlikely.

 

Is your client multi-threaded?

 

 

Martin

 

From: ope...@googlegroups.com <ope...@googlegroups.com> On Behalf Of Kevin Powick

 

 

Sent: 17 January 2021 18:37
To: OpenQM <ope...@googlegroups.com>
Subject: QMClient: illegal action code (10001)

--
You received this message because you are subscribed to the Google Groups "OpenQM" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openqm+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openqm/3fa21104-9ca9-4595-8d1a-ec22c0f44624n%40googlegroups.com.

[Kevin Powick]

Hi Martin,

I'll continue our conversation via the private emails we are already exchanging and follow-up here once a resolution is found.

However, the client is not multi-threaded.  It happens all the time.  There are no other connections to QM at the time this is happening.  It is a first QMConnect() attempt from the client software.

The only major change to the system is that the host OS for QM has been upgraded to macOS Big Sur from Mojave (skipped Catalina).  Apple has definitely made some security changes since Mojave, which is a possible reason for the connection issue.

--

Kevin Powick

[Martin Phillips]

Solved.

 

The qmlnxd process is primarily responsible for launching a new QM process when a network connection arrives though it does other things too. QM allows this process to run as root or non-root with a subtle but important difference.

 

For a secure system, qmlnxd should run as root. It then has access to the necessary APIs to create the child QM process as the user identified in the authentication mechanism. For QMClient, that is the details pass to QMConnect(). Users must connect with a username and password known to the underlying o/s and all the security related stuff built around Linux file permissions come into play.

 

Running qmlnxd as a non-root user is possible but nowhere near as secure because the child process cannot change its uid/gid to become someone else. Instead, the child process runs as the same user as qmlnxd.

 

There was a defect in the server side of QMClient which affected only non-root use of qmlnxd and caused the client side to attempt the secure login. This was fixed in QM release 3.4-13.

 

Quite why upgrading the o/s led to qmlnxd being non-root is unclear but appears to be caused by changes introduced by Apple relating to system security.

To view this discussion on the web visit https://groups.google.com/d/msgid/openqm/1e742823-cae2-4135-97d0-67e6483aac38n%40googlegroups.com.

[Kevin Powick]

As Martin has noted, the problem was that the QM service daemon "qmlnxd" was not running as root.

On my mac, I have two accounts;  an admin account and my regular user account.  For security/safety, I typically work on my mac logged in under my non-privileged user account.  For actions that require root permissions, such as launching the QM daemon (qmlndxd), I would use sudo from the command line (e.g. sudo qm -start).

After my recent macOS upgrade, my regular user account was automatically removed from the sudoers file, preventing me from using sudo.  So, I used "su admin" to gain admin level rights, then start QM.  Unfortunately, this ran qmlnxd as admin, not root; An important distinction explained in Martin's previous post.

The "fix" was to get my user account back into the sudoers file.  However, getting that done on the Mac is easier said than done.  That file is only accessible via root privileges, and the root account is disabled by default on macOS.  The following link explains how to enable the root account on macOS https://support.apple.com/en-us/HT204012

Once the root account was enabled, I could use visudo as root to update the sudoers file.  And once my regular user account was back in sudoers, I could "sudo qm -start" to get qmlnxd running as root.  This corrected the problem with QMClient connections. 

Thanks to Martin for his great support!

--

Kevin Powick