| Author |
Message
|
| veech23 |
 Posted: Thu Oct 08, 2009 9:55 pm Post subject: receiver channel scratchpad errors |
 |
|
Novice
Joined: 25 Apr 2007
Posts: 23
Location: canberra
|
Hi all, trying to implement
http://t-rob.net/2008/07/08/websphere-mq-security-heats-up/
i am getting the following error
AMQ9587: Program cannot open queue manager object.
EXPLANATION:
The attempt to open object '%CHLBATCH.10' on queue manager 'QM1' failed
with reason code 2035.
Env : RHEL4.6 32 bit QM1 wmq 7.0.1.0
Env : z/os QM2 wmq 5.3
I am under the impression that since channel process is running under mqm, it would be used to do all magic behind the scences
of create/maintain of scratchpad objects. But when a message comes from QM2 via QM2_TO_QM1 receiver channel which has PUTAUT(DEF) and MCAUSER('mqmmca'), i am seeing the above error.
what am i missing???
mqmmca is a local group
mqmmca has no permissions in QM1 scratchpad directory
[mqmmca@xxxxxxx ~]$ ls -al /var/mqm/qmgrs/QM1/scratch/
ls: /var/mqm/qmgrs/QM1/scratch/: Permission denied
mqmmca has permissions in QM1 as follows
/usr/bin/setmqaut -m QM1 -t qmgr -g mqmmca -all +connect +inq +setall
/usr/bin/setmqaut -m QM1 -t q -n '**' -g mqmmca -all +put +setall
/usr/bin/setmqaut -m QM1 -g mqmmca -n '**' -t topic -all +pub +setall
/usr/bin/setmqaut -m QM1 -t q -n SYSTEM.'**' -g mqmmca -all
/usr/bin/setmqaut -m QM1 -t q -n SYSTEM.CLUSTER.COMMAND.QUEUE -g mqmmca -all +inq +put +setall
/usr/bin/setmqaut -m QM1 -t q -n SYSTEM.MQEXPLORER.REPLY.MODEL -g mqmmca +inq +browse +get +dsp +setall
/usr/bin/setmqaut -m QM1 -t q -n SYSTEM.DEFAULT.MODEL.QUEUE -g mqmmca -all +allmqi +dsp +setall
receiver channel
DEFINE CHANNEL ('QM2_TO_QM1') CHLTYPE(RCVR) +
TRPTYPE(TCP) +
BATCHSZ(1) +
HBINT(300) +
MAXMSGL(4096) +
MCAUSER('mqmmca') +
MRDATA(' ') +
MREXIT(' ') +
MRRTY(10) +
MRTMR(1000) +
MSGDATA(' ') +
MSGEXIT(' ') +
NPMSPEED(FAST) +
PUTAUT(DEF) +
RCVDATA(' ') +
RCVEXIT(' ') +
SCYDATA(' ') +
SCYEXIT(' ') +
SENDDATA(' ') +
SENDEXIT(' ') +
SEQWRAP(999999999) +
SSLCAUTH(REQUIRED) +
SSLCIPH(' ') +
SSLPEER(' ') +
KAINT(AUTO) +
MONCHL(QMGR) +
STATCHL(QMGR) +
COMPMSG(NONE) +
COMPHDR(NONE) +
REPLACE |
|
| Back to top |
|
 |
| Mr Butcher |
| Posted: Thu Oct 08, 2009 11:00 pm Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
afaik, you need a user in the MCA attribute, not a groupname. so define a user , make it member of the mqmmca group and use that user in MCA and that should work
_________________
Regards, Butcher |
|
| Back to top |
|
|
| veech23 |
| Posted: Fri Oct 09, 2009 12:04 am Post subject: |
|
|
Novice
Joined: 25 Apr 2007
Posts: 23
Location: canberra
|
| hi, there is a local user with the same name mqmmca |
|
| Back to top |
|
|
| T.Rob |
| Posted: Mon May 24, 2010 1:38 pm Post subject: V7 broke this but it's been fixed |
|
|
Acolyte
Joined: 16 Oct 2001
Posts: 56
Location: Charlotte, NC
|
There was a change in v7 where the channel's use of scratchpad files was tied to the +crt authorization. Unfortunately, this meant that the MCAUSER had to have admin rights, albeit indirectly, through granting +crt on queues. After a PMR and some discussion, the behavior was reverted back. I forget which Fix Pack that was but It should work as described in the current versions of WMQ (7.0.1.2 as I write this.)
_________________
-- T.Rob
Voice/SMS 704-443-TROB (8762)
https://t-rob.net
https://linkedin.com/in/tdotrob
@tdotrob on Twitter |
|
| Back to top |
|
|
| jeevan |
| Posted: Wed May 26, 2010 8:55 am Post subject: Re: V7 broke this but it's been fixed |
|
|
Grand Master
Joined: 12 Nov 2005
Posts: 1432
|
| T.Rob wrote: |
| There was a change in v7 where the channel's use of scratchpad files was tied to the +crt authorization. Unfortunately, this meant that the MCAUSER had to have admin rights, albeit indirectly, through granting +crt on queues. After a PMR and some discussion, the behavior was reverted back. I forget which Fix Pack that was but It should work as described in the current versions of WMQ (7.0.1.2 as I write this.) |
T.Rob,
We have an issue with scratchpad files. Some of scratchpad files at one of our gateway qmgrs have been corrupted and we can not use the link to go to some of the stores. we are eventually rebuilding the queue manager ( in fact we are migrating both software and hardware as we are still running MQ6 with this qmgr) but is there anyway to fix this problem for time being. Can we delete the channel and the file ? or can we create another cluster receiver channel at gateway qmgr, and stop the one existing. so when a need exists to connect to the gateway qamgr, the store make connection to the new channel. would this work?
or can we delete the file itself? i thought a scratchpad file has informaiton for more than one channel.
thanks |
|
| Back to top |
|
|
| T.Rob |
| Posted: Wed May 26, 2010 11:36 am Post subject: Re: V7 broke this but it's been fixed |
|
|
Acolyte
Joined: 16 Oct 2001
Posts: 56
Location: Charlotte, NC
|
Sorry, but it sounds like PMR time. The use of scratchpad and other internals is subject to change from version to version. What little I know about the internals comes from Mark Taylor's WMQ Internals session at the conference and that is really a snapshot of WMQ at a point in time. I'd hate to make a recommendation and find out it's wrong.
If you do have to recreate the QMgr, remember it's not the same QMgr. It will have a different QMID so you will want to reset the old one out of the cluster, preferably before joining up the new one.
Was the scratchpad damage correlated with first use of the low-privileged MCAUSER under v7? In other words, do you have reason to suspect the auth error to be the root of the problem?
| Quote: |
T.Rob,
We have an issue with scratchpad files. Some of scratchpad files at one of our gateway qmgrs have been corrupted and we can not use the link to go to some of the stores. we are eventually rebuilding the queue manager ( in fact we are migrating both software and hardware as we are still running MQ6 with this qmgr) but is there anyway to fix this problem for time being. Can we delete the channel and the file ? or can we create another cluster receiver channel at gateway qmgr, and stop the one existing. so when a need exists to connect to the gateway qamgr, the store make connection to the new channel. would this work?
or can we delete the file itself? i thought a scratchpad file has informaiton for more than one channel.
thanks |
_________________
-- T.Rob
Voice/SMS 704-443-TROB (8762)
https://t-rob.net
https://linkedin.com/in/tdotrob
@tdotrob on Twitter |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Wed May 26, 2010 3:13 pm Post subject: Re: V7 broke this but it's been fixed |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| jeevan wrote: |
| ... Can we delete the channel and the file ? |
Yes, that is worth trying, but make sure you have a full backup of the qmgr before proceeding.
| Quote: |
| .. or can we create another cluster receiver channel at gateway qmgr, and stop the one existing. so when a need exists to connect to the gateway qamgr, the store make connection to the new channel. would this work? |
Yes, that should work.
| Quote: |
| or can we delete the file itself? i thought a scratchpad file has informaiton for more than one channel. |
Now you are playing with fire  I believe each channel has a separate scratchpad file.
It is worth raising a PMR, as IBM may have more appropriate advice or actions for your situation.
_________________
Glenn |
|
| Back to top |
|
|
| hal |
| Posted: Thu May 27, 2010 9:09 am Post subject: |
|
|
Acolyte
Joined: 07 Dec 2005
Posts: 67
Location: New York City, New York
|
I am having the same receiver channel problems with WebSphere MQ 7.0.1.2.
I enable queue manager authorization events and use SupportPac MS0P to decipher binary SYSTEM.ADMIN.QMGR.EVENT messages via WebSphere MQ Explorer. So I could see that my non-administrative MCAUSER accounts did not have authorization to open the SYSTEM.CHANNEL.SYNCQ queue. After adding OAM authorizations the channels worked Ok.
A similar issue for CLUSRCVR channels is described at http://www-01.ibm.com/support/docview.wss?uid=swg1IZ61338&myns=swgws&mynp=OCSSFKSJ&mync=E
| Quote: |
A temporary workaround for this problem is to specifically grant
+crt authority to the SYSTEM.CHANNEL.SYNCQ for any affected
user. Any security implications should be understood before
making a change such as this. |
I opened a PMR with IBM about fixing RCVR channels configured with MCAUSER accounts that are unable to open the SYSTEM.CHANNEL.SYNCQ queue. |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Thu May 27, 2010 3:22 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| Quote: |
A temporary workaround for this problem is to specifically grant
+crt authority to the SYSTEM.CHANNEL.SYNCQ for any affected
user. Any security implications should be understood before
making a change such as this. |
Yes, granting +crt authority to any queue object actually grants this authority at the queue object class level. ie. The user / group will be able to define new queue objects with any name.
_________________
Glenn |
|
| Back to top |
|
|
| hal |
| Posted: Wed Jun 09, 2010 9:12 am Post subject: |
|
|
Acolyte
Joined: 07 Dec 2005
Posts: 67
Location: New York City, New York
|
From the IBM Change Team,
| Quote: |
We are discussing this problem, will be providing an update
by next week. |
|
|
| Back to top |
|
|
| hal |
| Posted: Mon Jul 26, 2010 2:10 pm Post subject: |
|
|
Acolyte
Joined: 07 Dec 2005
Posts: 67
Location: New York City, New York
|
The IBM Change Team created an APAR from my PMR. The non-administrative MCAUSER account id issue is scheduled to be fixed in WebSphere MQ 7.0.1.4.
From http://www-01.ibm.com/support/docview.wss?uid=swg1IZ78326&myns=swgws&mynp=OCSSFKSJ&mync=E
| Quote: |
IZ78326: WMQ V7.0.1.0 RCVR/CLUSRCVR CHANNELS REPORT AMQ9586/AMQ9587 and AMQ9999 WITH REASON CODE 2035
APAR status Closed as program error.
Error description
If the MCAUSER attribute of a CLUSRCVR/RCVR channel is
configured with a non-administrative user ID (not part of the
mqm group) then during channel startup or when a persistent
message flows through the channel, the CLUSRCVR/RCVR may
report AMQ9587 or AMQ9587 error and AMQ9999 error in the error
log and the channel will fail to start or the running channel
will end abnormally:
AMQ9587: Program cannot open queue manager object.
The attempt to open object '%CHLBATCH.4' on queue
manager 'RCVRQMGR' failed with reason code 2035.
AMQ9586: Program cannot create queue manager object. The
The attempt to create object '%CHLBATCH.6' on queue
manager 'RCVRQMGR' failed with reason code 2035.
AMQ9999: Channel program ended abnormally.
Channel program 'TESTCHL' ended abnormally.
AMQ8077 may also be reported with reason:
Entity fred has insufficient authority to access object
SYSTEM.CHANNEL.SYNCQ
The following requested permissions are unauthorized: crt
This problem may occur despite the same configuration working
correctly before 7.0.1.0 was installed.
Local fixAdd +all authorization to the SYSTEM.CHANNEL.SYNCQ for the
non-administrative userid.
Problem summary
****************************************************************
USERS AFFECTED:
Users of RCVR/CLUSRCVR channels whose MCAUSER attribute is
configured with a non-administrative user ID. The problem was
introduced in WebSphere MQ V7.0.1.0.
Platforms affected:
All Distributed (iSeries, all Unix and Windows)
****************************************************************
PROBLEM SUMMARY:
WMQ v7.0.1.0 introduced an authority check in order to
tighten security on MQ internal scratchpad objects.
A side-effect of this change is that specific authorities like
+crt, +dlt, +get and +put were needed on the
SYSTEM.CHANNEL.SYNCQ in order to create, delete and open the
scratchpad object.
The APAR IZ61338 removed some restrictions on these specific
authorities and now it requires +put on the
SYSTEM.CHANNEL.SYNCQ to access the scratchpad object.
Specific authority is required because the channel uses the
MCAUSER context for authorization. Scratchpad is an internal MQ
object. It is appropriate to use the Original User Context(the
user who started the MCA) instead of the MCAUSER context to
authorize the scratchpad object.
Problem conclusionScratchpad access functions have been modified to use the
Original User Context instead of the MCAUSER context
---------------------------------------------------------------
The fix is targeted for delivery in the following PTFs:
v7.0
Platform Fix Pack 7.0.1.4
-------- --------------------
Windows U200323
AIX U835793
HP-UX (PA-RISC) U836458
HP-UX (Itanium) U836463
Solaris (SPARC) U836459
Solaris (x86-64) U836465
iSeries tbc_p700_0_1_4
Linux (x86) U836460
Linux (x86-64) U836464
Linux (zSeries) U836461
Linux (Power) U836462 |
|
|
| Back to top |
|
|
|
|
