| Author |
Message
|
| abajt |
 Posted: Tue Jun 29, 2004 7:56 am Post subject: MQOPEN fails with reason code 2035 |
 |
|
Newbie
Joined: 01 May 2002
Posts: 5
|
Hi,
My app tries to open a queue with open options MQOO_FAIL_IF_QUIESCING + MQOO_SET_ALL_CONTEXT + MQOO_OUTPUT, and fails with reason code 2035 despite the user has all the necessary authorities given to his group via setmqaut.
I tried the same thing with the amqsput sample and get the same error :
./amqsput QTSWFANO QQEAIA1 10256
Sample AMQSPUT0 start
target queue is QTSWFANO
open options are 10256
MQOPEN ended with reason code 2035
unable to open queue for output
Sample AMQSPUT0 end
10256 = 0x2180 = MQOO_FAIL_IF_QUIESCING + MQOO_SET_ALL_CONTEXT + MQOO_OUTPUT
The authorities on the queue are : browse get inq passall passid put set setall setid (= +allmqi)
Even if I give all available (= +all) authorities to the group, I get same error. The amqsput sample works fine when executed under the mqm user.
I use WMQ 5.3 / CSD6 under Sun Solaris 2.8
Is there something wrong ?
André |
|
| Back to top |
|
 |
| RogerLacroix |
| Posted: Tue Jun 29, 2004 8:35 am Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3265
Location: London, ON Canada
|
Hi,
After you changed / updated the security setting with the setmqaut command, did you issue the REFRESH SECURITY command (in runmqsc)?
Do the dspmqaut command against the queue and group id and post the results here.
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Jun 29, 2004 12:43 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7723
|
Andre, on UNIX, you need to run the setmqaut command against the group, not the individual ID.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Jun 29, 2004 1:46 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20767
Location: LI,NY
|
Peter, andre
| Quote: |
| on UNIX, you need to run the setmqaut command against the group, not the individual ID |
Not quite true. You can run setmqaut with -p user but the stored authority is against the group. Check with dmpmqaut.
The question I have is have you granted access to the manager as well?
I usually grant +allmqi to the manager and the queue.
Never had a problem with that.
 |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Jun 29, 2004 4:57 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7723
|
| Quote: |
./amqsput QTSWFANO QQEAIA1 10256
Sample AMQSPUT0 start
target queue is QTSWFANO
open options are 10256
MQOPEN ended with reason code 2035
unable to open queue for output
Sample AMQSPUT0 end
|
| Quote: |
MQOPEN ended with reason code 2035
|
This indicates he has the proper permissions at the Queue Manager level, since he is getting past the MQCONN and failing on the MQOPEN.
Regarding using setmqaut with -p instead of -g, yes, you are correct that you can do it. That in itself should not cause the 2035 if everything else was in order. BUT, setting mq authorities by principals instead of groups can make life very difficult for you. From the SAG:
| Quote: |
All ACLs are based on groups. When a user is granted access to a particular resource, the user ID's primary group is included in the ACL, not the individual user ID, and authority is granted to all members of that group. Because of this, be aware that you could inadvertently change the authority of a principal by changing the authority of another principal in the same group.
|
It is possible he is giving +allmqi for userA in group1, and then -allmqi for userB in group1, thus possibly undoing userA's setting. It will be much clearer if you do the settings at the group level, even if you technically can set it at the user level.
Like Roger suggested, dspmqaut outputs for the queues / users in question should allow us to figure this out.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| abajt |
| Posted: Wed Jun 30, 2004 3:32 am Post subject: |
|
|
Newbie
Joined: 01 May 2002
Posts: 5
|
Hi,
Thank's for your replies.
Here are some more informations about actions done before my first post to this forum :
- The user 'myuser' is member of group 'mygroup', and authorities have been set to the group with 'setmqaut ... -g mygroup'
- A 'refresh security' has been done under runmqsc
- dpsmqaut gives this :
$ dspmqaut -m MYQM -n MYQ -t q -g mygroup
Entity mygroup has the following authorizations for object MYQ:
get
browse
put
inq
set
passid
passall
setid
setall
And... amqsput gives this :
$ ./amqsput MYQ MYQM 10256
Sample AMQSPUT0 start
target queue is MYQ
open options are 10256
MQOPEN ended with reason code 2035
unable to open queue for output
Sample AMQSPUT0 end
André |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Jun 30, 2004 5:01 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7723
|
What happens if you exclude the 10256 Open Options? (although you should work regardless with +allmqi)
And what does dspmqaut -m MYQM -t qmgr -g mygroup show? (although if there was a problem at the QM level, I would think - hope - you would see a 2035 on the MQCONN call)
Is MYQ a local queue? Or a Remote Queue Def? (not that it should make a diff).
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| abajt |
| Posted: Wed Jun 30, 2004 7:30 am Post subject: |
|
|
Newbie
Joined: 01 May 2002
Posts: 5
|
After many attempts, I have found where the problem was.
The authorities '+allmqi' for the group on the queue where right,
but the authorities on the qmgr object were only '+connect'.
When I set '+allmqi' authorities on the qmgr object, I have no more error 2035. Strange, isn't it ?
Thank's a lot.
André |
|
| Back to top |
|
|
| mqonnet |
| Posted: Wed Jun 30, 2004 7:49 am Post subject: |
|
|
Grand Master
Joined: 18 Feb 2002
Posts: 1114
Location: Boston, Ma, Usa.
|
Andre,
There *MUST* definitely be something else that you did in your numerous attempts. Because adding +allmqi to the qmgr object *would NOT* solve this problem.
Because you were getting 2035 on an mqopen call and not Mqconn. Which itself means, your userid was authenticated at the qmgr level, as already explained by Peter.
Cheers
Kumar
_________________
IBM Certified WebSphere MQ V5.3 Developer
IBM Certified WebSphere MQ V5.3 Solution Designer
IBM Certified WebSphere MQ V5.3 System Administrator |
|
| Back to top |
|
|
| abajt |
| Posted: Thu Jul 01, 2004 12:57 am Post subject: |
|
|
Newbie
Joined: 01 May 2002
Posts: 5
|
Hi,
Just read what follows...
(mqm) /opt/mqm/samp/bin $ dspmqaut -m MYQM -t qmgr -g mygroup
Entity mygroup has the following authorizations for object MYQM:
connect
(mqm) /opt/mqm/samp/bin $ dspmqaut -m MYQM -n MYQ -t q -g mygroup
Entity mygroup has the following authorizations for object MYQ:
get
browse
put
inq
set
passid
passall
setid
setall
(mqm) /opt/mqm/samp/bin $ su - myuser
Password:
Sun Microsystems Inc. SunOS 5.8 Generic Patch October 2001
(myuser)/export/apps/mygroup_qua $ cd /opt/mqm/samp/bin
(myuser)/opt/mqm/samp/bin $ ./amqsput MYQ MYQM 10256
Sample AMQSPUT0 start
target queue is MYQ
open options are 10256
MQOPEN ended with reason code 2035
unable to open queue for output
Sample AMQSPUT0 end
(myuser) /opt/mqm/samp/bin $ exit
(mqm) /opt/mqm/samp/bin $ setmqaut -m MYQM -t qmgr -g mygroup +allmqi
The setmqaut command completed successfully.
(mqm) /opt/mqm/samp/bin $ su - myuser
Password:
Sun Microsystems Inc. SunOS 5.8 Generic Patch October 2001
(myuser)/export/apps/mygroup_qua $ cd /opt/mqm/samp/bin
(myuser)/opt/mqm/samp/bin $ ./amqsput MYQ MYQM 10256
Sample AMQSPUT0 start
target queue is MYQ
open options are 10256
test message
Sample AMQSPUT0 end
(myuser)/opt/mqm/samp/bin $
Cheers
André |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Thu Jul 01, 2004 3:57 am Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Jul 01, 2004 4:46 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7723
|
light bulb just went on...
There are 3 components to +allmqi when you give it to the qmgr. They are connect, inq, altusr. Connect and inq are pretty obvious, but this is what the SAG says for altusr:
| Quote: |
Use another user's authority for MQOPEN and MQPUT1 calls.
|
altusr is only allowed to be set at the qmgr level, even though the MQCONN call has nothing to do with alternate IDs. That is very confusing!
But, it explains this scenario. Andre is using MQOPEN options that would allow him to use an Alternate User ID. So he needs +altusr authority. And for some reason, IBM choose to require this to be allowed/disallowed via setmqaut at the QM level. But its not until the MQOPEN call that that the lack of proper authority show itself. Hence, 2035 on the MQOPEN call, because you didn't set something correct at the qmgr level.
Any guesses as to why IBM did it this way?
_________________
Peter Potkay
Keep Calm and MQ On
Last edited by PeterPotkay on Thu Jul 01, 2004 5:01 am; edited 1 time in total |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Jul 01, 2004 4:59 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7723
|
Hmmm, maybe not. SET_ALL_CONTEXT doesn't look like it has anything to do with the alternate user id field in the MQOD. The context info in the MQMD only pertains the UserIdentifier, not the AlternateUserID in the MQOD.
But maybe this is somehow related anyway?
Or maybe because Andre is doing the su - myuser, MQ thinks he is running under an alternate user id? Dunno...
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| mqonnet |
| Posted: Thu Jul 01, 2004 8:08 am Post subject: |
|
|
Grand Master
Joined: 18 Feb 2002
Posts: 1114
Location: Boston, Ma, Usa.
|
altusr would come into the picture only if an alternate user authority is being used either directly or indirectly. Directly when someone sets this in their app. Indirectly when you have more than one userid for authentication purposes. A typical example is using MCAUSER on a channel.
In this particular case, my first question would be, whether you tried to logon(in a new shell session) using "myuser" and try running amqsput. Because i am not really sure how the SU'ing works and what userid/authority is used. One would expect it to use the SU'd userid authority, though.
How it looks to me is, since you logged on using mqm userid and then SU'd to "myuser", MQ considers it to be altusr status. And hence, logging in on a new session using myuser would prove whether this is true or not.
Theoretically, if you created a principal and assigned connect on a qmgr and all the permissions you need to, on a queue, you should be able to make the respective MQ API calls. IMHO.
Cheers
Kumar
_________________
IBM Certified WebSphere MQ V5.3 Developer
IBM Certified WebSphere MQ V5.3 Solution Designer
IBM Certified WebSphere MQ V5.3 System Administrator |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Thu Jul 01, 2004 8:49 am Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
| mqonnet wrote: |
| How it looks to me is, since you logged on using mqm userid and then SU'd to "myuser |
hmm maybe this is where the 'logic' breaks...
normally you su from myuser to mqm not the other way around.
simply log on as myuser and do what you need to do and see what
happens...
_________________
Michael
MQSystems Facebook page |
|
| Back to top |
|
|
|
|
