| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| 2035, mqm group, XA connection |
« View previous topic :: View next topic » |
| Author |
Message
|
| camauz |
 Posted: Thu Jan 31, 2008 1:46 am Post subject: 2035, mqm group, XA connection |
 |
|
Acolyte
Joined: 20 Aug 2007
Posts: 52
Location: Mojan, Italy
|
Hi all,
I am experiencing a strange behavior, I would be very happy if someone knows why it happens / may happen.
Environment:
AIX 5
WebSphere MQ 5.3
Microfocus Cobol 2.2
Oracle (client) 9.2
Issue description.
User "u1" is NOT in group "mqm".
User "u1" is in group "g1".
Group "g1" is granted to put message to queue "q1" (setmqaut).
User "u1" is able to put messages to queue "q1" using IBM sample "amqsput".
User "u1" is NOT able to put messages to queue "q1" using a COBOL program that connects to Oracle using XA (two phase commit is required).
User "u2" is in group "mqm".
User "u2" is in group "g1"
Group "g1" is granted to put message to queue "q1" (setmqaut).
User "u1" is able to put messages to queue "q1" using IBM sample "amqsput".
User "u1" is able to put messages to queue "q1" using a COBOL program that connects to Oracle using XA (two phase commit is required).
This is the question: is there any difference, from an authorization point of view, between a WSMQ stand alone application (amqsput) and a distributed transaction coordinated by XA?
No specific errors or messages are traced in:
- queue manager's error log
- general WSMQ error log
- XA trace file
I executed the COBOL application using "truss" and tracing all the system calls: it does not seem the problem is related to the access of a resource throught a system call (for example IPC semaphores and shared memories).
The decision seems to be inside MQ logic, it's not a consequence of a system call.
Is this behavior correct? Is it documented?
Any hint can help.
Thanks in advance
Regards
Ch. |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Thu Jan 31, 2008 2:09 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Turn on authority events and see what's being complained about. Maybe you need to grant +inq or etc to the queue instead of just +put.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| camauz |
| Posted: Thu Jan 31, 2008 3:14 am Post subject: |
|
|
Acolyte
Joined: 20 Aug 2007
Posts: 52
Location: Mojan, Italy
|
| jefflowrey wrote: |
| Turn on authority events and see what's being complained about. Maybe you need to grant +inq or etc to the queue instead of just +put. |
Such an interesting hint!
I'm discovering some details...
Analyzing...
Thanks
Ch. |
|
| Back to top |
|
|
| camauz |
| Posted: Thu Jan 31, 2008 9:03 am Post subject: |
|
|
Acolyte
Joined: 20 Aug 2007
Posts: 52
Location: Mojan, Italy
|
I've analyzed the authorization events and discovered some details. Unfortunately I'm not able to understand why the user is not able to opent the queue.
The produced events are all the same:
[ 300 bytes] Event Header (MQCFH)
Type :7
Struc Length :36
Version :1
Command :44 (QMgr Event)
Sequence No. :1
Control :1
CompCode :1
Reason :2035 (Not authorized.)
Parm Count :7
[ 264 bytes] String (MQCFST)
Type :4
Struc Length :68
Parameter Id :2015 (QMgr Name)
CCSID :850
String Length:48
Value :'QT1GD0A1 '
[ 196 bytes] Integer (MQCFIN)
Type :3
Struc Length :16
Parameter Id :1020 (Reason Qualifier)
Value :2 [0x'2'] MQRQ_OPEN_NOT_AUTHORIZED
[ 180 bytes] String (MQCFST)
Type :4
Struc Length :68
Parameter Id :2016 (Q Name)
CCSID :850
String Length:48
Value :'QT1GD0A1.PROVA '
[ 112 bytes] Integer (MQCFIN)
Type :3
Struc Length :16
Parameter Id :1022 (Open Options)
Value :10256 [0x'2810']
[ 96 bytes] String (MQCFST)
Type :4
Struc Length :32
Parameter Id :3025 (User Identifier)
CCSID :850
String Length:12
Value :'vianell3 '
[ 64 bytes] Integer (MQCFIN)
Type :3
Struc Length :16
Parameter Id :1 (Appl Type)
Value :6 [0x'6'] MQAT_AIX
[ 48 bytes] String (MQCFST)
Type :4
Struc Length :48
Parameter Id :3024 (Appl Name)
CCSID :850
String Length:28
Value :'SDGCFPM3 '
the principal (vianell3) is OK
the queue (QT1GD0A1.PROVA) is OK
the queue manager (QT1GD0A1) is OK
the open options passed to MQOPEN is x'2810'; I grabbed the include files and retrieved:
MQOO_FAIL_IF_QUIESCING 0x00002000
MQOO_SET_ALL_CONTEXT 0x00000800
MQOO_OUTPUT 0x00000010
the first option is not related to the authorization process.
MQOO_SET_ALL_CONTEXT requires MQZAO_SET_ALL_CONTEXT
MQOO_OUTPUT requires MQZAO_OUTPUT
enought:
MQOO_SET_ALL_CONTEXT implies:
MQOO_PASS_IDENTITY_CONTEXT 0x00000100 => requires MQZAO_PASS_IDENTITY_CONTEXT
MQOO_PASS_ALL_CONTEXT 0x00000200 => requires MQZAO_PASS_ALL_CONTEXT
MQOO_SET_IDENTITY_CONTEXT 0x00000400 => requires MQZAO_SET_IDENTITY_CONTEXT
It seems it is easy to solve...
I prepared this script:
$ cat foo.sh
#/bin/ksh
setmqaut -m QT1GD0A1 -n QT1GD0A1.PROVA -t queue -g sdgappl +all
runmqsc QT1GD0A1 <<EOF
REFRESH SECURITY (*)
EOF
dmpmqaut -m QT1GD0A1 -n QT1GD0A1.PROVA -t queue
and executed it:
$ ./foo.sh
The setmqaut command completed successfully.
5724-B41 (C) Copyright IBM Corp. 1994, 2002. ALL RIGHTS RESERVED.
Starting MQSC for queue manager QT1GD0A1.
1 : REFRESH SECURITY (*)
AMQ8560: WebSphere MQ security cache refreshed.
One MQSC command read.
No commands have a syntax error.
All valid MQSC commands were processed.
profile: QT1GD0A1.PROVA
object type: queue
entity: mqm
entity type: group
authority: allmqi dlt chg dsp clr
- - - - - - - -
profile: QT1GD0A1.PROVA
object type: queue
entity: sdgappl
entity type: group
authority: allmqi dlt chg dsp clr
- - - - - - - -
profile: **
object type: queue
entity: sdgappl
entity type: group
authority: get browse put inq dsp passall setall
the user "vianell3" is in group "sdgappl":
[vianell3@sdgads01-test1]/$id
uid=227(vianell3) gid=206(sdgappl) groups=1(staff),5000(Tivoli)
But the issue is the same.
Any hints to inspect the problem is welcomed!
Thanks in advance
Ch. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Jan 31, 2008 9:09 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
You don't have permissions to the qmgr that you need.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Nigelg |
| Posted: Thu Jan 31, 2008 9:46 pm Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004
Posts: 1046
|
Good analysis, poor execution of solution.
From the System Admin manual
| Quote: |
Authorizations for context
passall Pass all context on the specified queue. All the context fields are copied from the original request.
passid Pass identity context on the specified queue. The identity context is the same as that of the request.
setall Set all context on the specified queue. This is used by special system utilities.
setid Set identity context on the specified queue. This is used by special system utilities.
|
Use +setall to confer the required authority.
BTW, REFRESHH SECURITY only needs to be used when a new O/S user or group has been added. You do not need to run it after a setmqaut command.
_________________
MQSeries.net helps those who help themselves.. |
|
| Back to top |
|
|
| camauz |
| Posted: Fri Feb 01, 2008 3:38 am Post subject: |
|
|
Acolyte
Joined: 20 Aug 2007
Posts: 52
Location: Mojan, Italy
|
| jefflowrey wrote: |
| You don't have permissions to the qmgr that you need. |
Thanks!
This solved my problem:
setmqaut -m $1 -t qmgr -g sdgappl +allmqi
Unfortunately a different program exploits a different 2035 issue, but this is different stuff!
Regards
Ch. |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
