0


Hi guys.
I've an IBM MQ image deployed on Openshift 4 and for some reason, the processes don't use the user mqm but the one randomly generated by Openshift itself.

As a result, I've a Java application that tries to connect to the queues and it fails because the authentication fails since it uses mqm as user.

The same exact image running on Openshift 3 behaves as expected. For more details:
Custom image:

FROM ibmcom/mq
ENV HOME /root
COPY config.mqsc /etc/mqm/

and, in the config.mqsc:

DEFINE CHANNEL(PASSWORD.SVRCONN) CHLTYPE(SVRCONN)
SET CHLAUTH(PASSWORD.SVRCONN) TYPE(BLOCKUSER) USERLIST('nobody') DESCR('Allow privileged users on this channel')
SET CHLAUTH('*') TYPE(ADDRESSMAP) ADDRESS('*') USERSRC(NOACCESS) DESCR('BackStop rule')
SET CHLAUTH(PASSWORD.SVRCONN) TYPE(ADDRESSMAP) ADDRESS('*') USERSRC(CHANNEL) CHCKCLNT(REQUIRED)
ALTER AUTHINFO(SYSTEM.DEFAULT.AUTHINFO.IDPWOS) AUTHTYPE(IDPWOS) ADOPTCTX(YES)
REFRESH SECURITY TYPE(CONNAUTH)

DEFINE QLOCAL(MYQUEUE.IN ) DEFPSIST(YES) MAXDEPTH(500000)
DEFINE QLOCAL(MYQUEUE.OUT ) DEFPSIST(YES) MAXDEPTH(500000)

DEFINE QLOCAL(CS.ERROR) DEFPSIST(YES) MAXDEPTH(500000)

ALTER QMGR CHLAUTH(DISABLED) CONNAUTH(' ')
ALTER CHANNEL('SYSTEM.DEF.SVRCONN') CHLTYPE(SVRCONN) MCAUSER('mqm')
REFRESH SECURITY TYPE(CONNAUTH)

The process running on Openshift 4 looks like

1000790+     232  0.0  0.1 2308688 45776 ?       Ssl  09:39   0:00 /opt/mqm/bin/amqzxma0 -m QM1 -x -u 1000790000

but in the Openshift 3 it looks like

1000100+    152  0.0  0.0 2324200 33812 ?       Ssl  May03   0:06 /opt/mqm/bin/amqzxma0 -m QM1 -x -u mqm

Another difference are the "capabilties" and the security attributes that the MQ container has on startup.
On Openshift 3:

Capabilities (bounding set): chown,dac_override,fowner,fsetid,setpcap,net_bind_service,net_raw,sys_chroot,audit_write,setfcap
Process security attributes: system_u:system_r:container_t:s0:c0,c15

On Openshift 4:

Capabilities (bounding set): chown,dac_override,fowner,fsetid,setpcap,net_bind_service,net_raw,sys_chroot
Process security attributes: system_u:system_r:container_t:s0:c17,c28

Stacktrace produced by the application:

Caused by: org.springframework.jms.JmsSecurityException: JMSWMQ2013: The security authentication was not valid that was supplied for QueueManager 'QM1' with connection mode 'Client' and host name 'my-mq(1414)'.; nested exception is com.ibm.msg.client.jms.DetailedJMSSecurityException: JMSWMQ2013: The security authentication was not valid that was supplied for QueueManager 'QM1' with connection mode 'Client' and host name 'my-mq(1414)'.
Please check if the supplied username and password are correct on the QueueManager to which you are connecting.; nested exception is com.ibm.mq.MQException: JMSCMQ0001: IBM MQ call failed with compcode '2' ('MQCC_FAILED') reason '2035' ('MQRC_NOT_AUTHORIZED').
        at org.springframework.jms.support.JmsUtils.convertJmsAccessException(JmsUtils.java:286)
        at org.springframework.jms.support.JmsAccessor.convertJmsAccessException(JmsAccessor.java:185)
        at org.springframework.jms.core.JmsTemplate.execute(JmsTemplate.java:507)
        at org.springframework.jms.core.JmsTemplate.browseSelected(JmsTemplate.java:1029)
        at org.springframework.jms.core.JmsTemplate.browse(JmsTemplate.java:991)
        ... 78 more
    Caused by: com.ibm.msg.client.jms.DetailedJMSSecurityException: JMSWMQ2013: The security authentication was not valid that was supplied for QueueManager 'QM1' with connection mode 'Client' and host name 'my-mq(1414)'.
Please check if the supplied username and password are correct on the QueueManager to which you are connecting.
        at com.ibm.msg.client.wmq.common.internal.Reason.reasonToException(Reason.java:531)
        at com.ibm.msg.client.wmq.common.internal.Reason.createException(Reason.java:215)
        at com.ibm.msg.client.wmq.internal.WMQConnection.<init>(WMQConnection.java:424)
        at com.ibm.msg.client.wmq.factories.WMQConnectionFactory.createV7ProviderConnection(WMQConnectionFactory.java:8475)
        at com.ibm.msg.client.wmq.factories.WMQConnectionFactory.createProviderConnection(WMQConnectionFactory.java:7815)
        at com.ibm.msg.client.jms.admin.JmsConnectionFactoryImpl._createConnection(JmsConnectionFactoryImpl.java:303)
        at com.ibm.msg.client.jms.admin.JmsConnectionFactoryImpl.createConnection(JmsConnectionFactoryImpl.java:236)
        at com.ibm.mq.jms.MQConnectionFactory.createCommonConnection(MQConnectionFactory.java:6016)
        at com.ibm.mq.jms.MQQueueConnectionFactory.createQueueConnection(MQQueueConnectionFactory.java:111)
        at com.ibm.mq.jms.MQQueueConnectionFactory.createConnection(MQQueueConnectionFactory.java:187)
        at org.springframework.jms.support.JmsAccessor.createConnection(JmsAccessor.java:196)
        at org.springframework.jms.core.JmsTemplate.execute(JmsTemplate.java:494)
        ... 80 more
    Caused by: com.ibm.mq.MQException: JMSCMQ0001: IBM MQ call failed with compcode '2' ('MQCC_FAILED') reason '2035' ('MQRC_NOT_AUTHORIZED').
        at com.ibm.msg.client.wmq.common.internal.Reason.createException(Reason.java:203)
        ... 90 more

Any idea on what the issue could be?

cdprete
  • 53
  • 1
  • 9
  • Are you asking why IBM MQ on Openshift 4 does not use mqm, or are you asking how to set up a non mqm user to connect to an IBM MQ queue manager because of the new way of running in Openshift 4? – Morag Hughson May 04 '21 at 11:01
  • In order to write an answer for the latter I need a little more information. Your script sets up CONNAUTH and then later disables it? Are you intending to use CONNAUTH password checking or not. Your script sets up CHLAUTH rules and then later disables it too. Are you intending to use CHLAUTH rules? You define two SVRCONN channels. Which one is your application actually using - I hope it is not SYSTEM.DEF.SVRCONN!! – Morag Hughson May 04 '21 at 11:12
  • @MoragHughson I would like to understand why Openshift 4 is not using `mqm` when Openshift 3 uses it instead and how I can configure Openshift 4 so that it uses `mqm` – cdprete May 04 '21 at 11:39
  • @MoragHughson and yes, as channel we're using `SYSTEM.DEF.SVRCONN` (don't ask me why :D) – cdprete May 04 '21 at 11:41
  • PS: this environment is used just for testing purposes, so it's not a production environment. – cdprete May 04 '21 at 11:51
  • So I think your question is, "How do I reinstate the privileged user/group, aka mqm when running IBMMQ in OpenShift 4" – Morag Hughson May 04 '21 at 12:47
  • It's also ok if it solves the issue :D – cdprete May 04 '21 at 13:01
  • @MoragHughson if I use the same UID everywhere (aka in the `config.mqsc` file as well as in the Java application) it works as expected somehow... – cdprete May 04 '21 at 14:02

1 Answers1

0

To ensure compliance with security constraints required in a multi-tenant containerized environment, the IBM MQ certified containers, do not support the use of IDs that are defined on the operating system libraries inside a container. There is no mqm user ID or group defined in the container.

For more details read User authentication and authorization for IBM MQ in containers

Morag Hughson
  • 7,255
  • 15
  • 44
  • This I got it by having a look at the Dockerfile, but still on Openshift 3 `amqzxma0` is using correctly `mqm` as value for the `-u` option. There is no real `mqm` user nor group on Openshift 3 as well. – cdprete May 04 '21 at 11:32