| Author |
Message
|
| Ross |
 Posted: Wed Nov 03, 2010 8:28 am Post subject: QA and S.C.T.Q - RACF Question |
 |
|
Centurion
Joined: 15 Jun 2005
Posts: 127
Location: Ireland
|
Hi,
I'm investigating RACF security needs for an application (IBM Product Started Task) that needs to put a message to a QA on a z/OS Queue Manager in an MQ Cluster.
The z/OS Qmgr, WMQ V6, is a PR in an MQ Cluster.
The Queue is a non-clustered QA, pointing to a local queue on a qmgr in the cluster, but not defined locally on the z/os qmgr. (It shows with a DIS CLUSQ on the z/OS qmgr).
The question is:
Is it right that the application needs READ access to the S.C.T.Q.? I expected RACF access to the QA to be sufficient.
I understand that the message is actually going to the S.C.T.Q.
I see the following from the QM Clusters manual, but in the "Platforms other than z/OS" section (Page 86).
****************
It is possible to avoid the need to give general access to all cluster resources and +Put access to the transmit queue. You do this by defining alias or remote queue definitions on your machine which resolve to queues in the cluster, and giving the appropriate authority for access to these instead of the cluster transmit queue. For example, suppose there is a queue called Q1 in the clusters to which your queue manager CORK belongs.
If you DEFINE QALIAS(Q1) TARGQ(Q1) DEFBIND(NOTFIXED) and then
setmqaut -m CORK -t qmgr -p GUEST +connect
setmqaut -m CORK -t queue -n Q1 -p GUEST -all +put
The user GUEST would only be able to send messages to the cluster queue Q1. Restricting access to your queues
Note that it is not possible to use the same technique for a queue manager alias, because this requires access to the underlying SYSTEM.CLUSTER.TRANSMIT.QUEUE queue.
***********************
I am just looking to clarify this before PErmitting read access to the S.C.T.Q. for this STC UserID.
Thanks,
Ross. |
|
| Back to top |
|
 |
| Vitor |
| Posted: Wed Nov 03, 2010 8:50 am Post subject: Re: QA and S.C.T.Q - RACF Question |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Ross wrote: |
The question is:
Is it right that the application needs READ access to the S.C.T.Q.? I expected RACF access to the QA to be sufficient.
I understand that the message is actually going to the S.C.T.Q.
|
I could be being a bit thick here, but I'm not sure I get your topology,
The QA is on a z/OS queue manager that's a member of a cluster. The QA is not in the cluster, but the local queue to which it points is. So far so good? If not, what?
If so, what does READ authority on the SCTQ have to do with anything? If you were putting to a queue you'd need UPDATE at least.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Nov 03, 2010 11:33 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| Quote: |
| Note that it is not possible to use the same technique for a queue manager alias, because this requires access to the underlying SYSTEM.CLUSTER.TRANSMIT.QUEUE queue. |
How so?
You can also define either the alias queue or the qmgr alias on the same qmgr and authorize it:
| Code: |
| def qr(remoteqmgr) rqmname(remoteqmgr) |
Note that the absence of an xmitq is only admissible in a cluster.
And no you do not authorize the SCTQ you authorize REMOTEQMGR.
Just remember that the put authorization for an ALIAS qmgr authorizes all queues on said target qmgr for put on the qmgr the alias resides on.
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Ross |
| Posted: Thu Nov 04, 2010 4:13 am Post subject: Re: QA and S.C.T.Q - RACF Question |
|
|
Centurion
Joined: 15 Jun 2005
Posts: 127
Location: Ireland
|
| Vitor wrote: |
The QA is on a z/OS queue manager that's a member of a cluster. The QA is not in the cluster, but the local queue to which it points is. So far so good? If not, what? |
Correct, QA not clustered. Local Queue is clustered, but hosted on another ClusQM.
| Vitor wrote: |
If so, what does READ authority on the SCTQ have to do with anything? If you were putting to a queue you'd need UPDATE at least. |
This is what I am surprised at. I have permitted RACF Update Access for the STC UserID to the MQQUEUE objects HLQ. The QA falls under this HLQ.
- For this project, all queues on z/os are named PROJ1.*, so I have permitted Update access by this STC User to MQQUEUE QMGR1.PROJ1.**
We get an ICH408I (RACF ERROR, ie MQ2035) for READ access to the S.C.T.Q.
I don't know what read access does in MQ, as I believe Update access is required to "Read" a queue, as you said.
Thanks.
Ross. |
|
| Back to top |
|
|
| Mr Butcher |
| Posted: Thu Nov 04, 2010 4:27 am Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
what kind of application program is that? i remember funny things java / jms or whatever doing inquiries for queuedepth before putting screwing up any security concept. As the QA resolves to the S.C.T.Q it may be something like this ..... an inquiry (after naming resolution) would explain it as it requires read access ....
_________________
Regards, Butcher |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Nov 04, 2010 4:31 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Mr Butcher wrote: |
| what kind of application program is that? i remember funny things java / jms or whatever doing inquiries for queuedepth before putting screwing up any security concept. As the QA resolves to the S.C.T.Q it may be something like this ..... an inquiry (after naming resolution) would explain it as it requires read access .... |
This is a good catch - the application trying a browse would explain this.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Ross |
| Posted: Thu Nov 04, 2010 4:35 am Post subject: |
|
|
Centurion
Joined: 15 Jun 2005
Posts: 127
Location: Ireland
|
| fjb_saper wrote: |
| Quote: |
| Note that it is not possible to use the same technique for a queue manager alias, because this requires access to the underlying SYSTEM.CLUSTER.TRANSMIT.QUEUE queue. |
How so?
You can also define either the alias queue or the qmgr alias on the same qmgr and authorize it:
| Code: |
| def qr(remoteqmgr) rqmname(remoteqmgr) |
Note that the absence of an xmitq is only admissible in a cluster.
And no you do not authorize the SCTQ you authorize REMOTEQMGR.
Just remember that the put authorization for an ALIAS qmgr authorizes all queues on said target qmgr for put on the qmgr the alias resides on.
Have fun |
Thanks for the response.
The quote you responded to above is not my statement, but rather taken from the QM Clusters manual.
I don't believe I need to use QM Aliases, as all QMs involved are in the Cluster.
The reason for the QA is the standard being used by the architects, to control PUT/GET access to local queues generally.
Just to clarify, I'm not making assumptions about this read access, I'm getting a RACF error. (ICH408I)
Thanks,
Ross. |
|
| Back to top |
|
|
| Ross |
| Posted: Thu Nov 04, 2010 4:40 am Post subject: |
|
|
Centurion
Joined: 15 Jun 2005
Posts: 127
Location: Ireland
|
| Mr Butcher wrote: |
| what kind of application program is that? i remember funny things java / jms or whatever doing inquiries for queuedepth before putting screwing up any security concept. As the QA resolves to the S.C.T.Q it may be something like this ..... an inquiry (after naming resolution) would explain it as it requires read access .... |
It is an IBM Product, IBM Infosphere Data Event Publisher V9.1.
It captures DB2 information, and publishes XML messages through MQ to WMB (in our case).
Thanks for the information. I'll look into it. Sounds plausible! |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Nov 04, 2010 7:12 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
When you have to give access to the S.C.T.Q., you can minimize the exposure by running all your Cluster Receiver channels with an MCAUSER ID filled in that is limited in what it can do, for example not being able to put messages to the SYSTEM.ADMIN.COMMAND.QUEUE. At least then you can prevent remote administration of your QMs from other QMs.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| Mr Butcher |
| Posted: Thu Nov 04, 2010 11:19 pm Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
if you dont get the information from IBM about the queue open options or if the queue is opened for browse, you can consider to run a GTF trace. In the trace you can see what the application is really doing, which queue is opened, which open options are used and so on.
I know this sounds a bit "oversized", but however if you never done a GTF trace before its a good practice and learning experience without the preasure of a real and urgend production problem......... and you are prepared if you really need one.
How to run the GTF trace is well explained in the documents, you may need to see your z/OS system programmer as GTF tracing may already be set up for other products....
_________________
Regards, Butcher |
|
| Back to top |
|
|
| Ross |
| Posted: Fri Nov 05, 2010 3:08 am Post subject: |
|
|
Centurion
Joined: 15 Jun 2005
Posts: 127
Location: Ireland
|
Thanks Mr Butcher.
I'll use this if I need to. As you say, might be a good exercise.
Peter, I'll stay away from MCAUSERIDs if possible, as I'll have the system queues locked down anyway, and permit read to this 1 userid only if necessary. I'll be sticking with a UACC of NONE. |
|
| Back to top |
|
|
| Ross |
| Posted: Sat Nov 06, 2010 3:34 pm Post subject: |
|
|
Centurion
Joined: 15 Jun 2005
Posts: 127
Location: Ireland
|
Thanks for all the help guys.
IBM confirmed that the product (Q Capture) inquires to see the max message size of the XMITQ, so that it doesn't create a messages that are too big to be transmitted.
It doesn't seem to be documented though.
At least it explains the symptoms...
Thanks,
Ross. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Sun Nov 07, 2010 6:38 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| Ross wrote: |
IBM confirmed that the product (Q Capture) inquires to see the max message size of the XMITQ, so that it doesn't create a messages that are too big to be transmitted.
|
I wonder if its also checking the Queue Manager's Max Message Size, the sending channel's Max Message Size. And how does it deal with the inability to know the Max Message size parameters on the receiving end - the QM, the receiving channel, the receiving queue.
Having an application nosing around the infrastructure layer seems like the sort of thing we would tell newbies not to do if they proposed that design for their new app.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| Ross |
| Posted: Sun Nov 07, 2010 12:34 pm Post subject: |
|
|
Centurion
Joined: 15 Jun 2005
Posts: 127
Location: Ireland
|
| PeterPotkay wrote: |
I wonder if its also checking the Queue Manager's Max Message Size, the sending channel's Max Message Size. And how does it deal with the inability to know the Max Message size parameters on the receiving end - the QM, the receiving channel, the receiving queue.
Having an application nosing around the infrastructure layer seems like the sort of thing we would tell newbies not to do if they proposed that design for their new app. |
The product is writing to a queue. Not necessarily aware that another qmgr is involved, it seems just an inquire on the queue that the publication is publishing to.
Regarding newbies, you know what these IBM folk are like!!!
Although I think they acquired this product, so perhaps the logic too. |
|
| Back to top |
|
|
|
|
