Browse issued turns into destructive get

Discussion:

Chad Little

2014-07-21 01:18:51 UTC

I have noticed an interesting behavior lately with MQ 7.5, specifically on RHEL. Similar configuration exists on 7.1 queue managers on other operating systems but I am not pinning this to 7.5 necessarily.

The same result has happened with two programs. One is a monitoring product and the other is Paul's q program (V 6.0).

Using the -i (lowercase eye) for browse, the API call generated in the queue manager is a destructive get. The requirement is some users should only have browse access. As such +dsp, +inq, and +browse were given to the queue along with +connect, +dsp, and +inq to the queue manager. When the user issues q with the -i, they receive a 2035 and a trace validates that the call they are not authorized for is +get on the queue object.

Anybody have any idea how/why a browse issued would turn into a destructive get?

Thanks.
Chad

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES

Paul Clarke

2014-07-21 05:03:07 UTC

Permalink

X-CTCH-Spam: Unknown
Received: from PAM7 (86.134.134.185) by smtpout20.bt.lon5.cpcloud.co.uk
(8.6.100.99.10223) (authenticated as paul.clarke85) id
53BF1E17004589AD for MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org; Mon, 21 Jul
2014 06:03:11 +0100
X-Priority: 3
X-MSMail-Priority: Normal
Importance: Normal
X-Mailer: Microsoft Windows Live Mail 15.4.3555.308
X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3555.308
X-PMX-Version: 6.1.0.2415318, Antispam-Engine: 2.7.2.2107409,
Antispam-Data: 2014.7.21.43620
X-PMX-Spam: Gauge=IIIIIIII, Probability=8%, Report=' AT_TLD 0.1,
HTML_00_01 0.05, HTML_00_10 0.05, BODYTEXTP_SIZE_3000_LESS 0,
BODY_SIZE_2000_2999 0, BODY_SIZE_5000_LESS 0,
BODY_SIZE_7000_LESS 0, DKIM_SIGNATURE 0, INVALID_MSGID_NO_FQDN 0,
NO_REAL_NAME 0, URI_ENDS_IN_HTML 0, __ANY_URI 0,
__BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0,
__CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0,
__FRAUD_WEBMAIL 0, __FRAUD_WEBMAIL_FROM 0, __HAS_FROM 0,
__HAS_MSGID 0, __HAS_MSMAIL_PRI 0, __HAS_X_MAILER 0,
__HAS_X_PRIORITY 0, __IN_REP_TO 0, __MIME_TEXT_ONLY 0,
__MIME_VERSION 0, __MSGID_32HEX 0, __PHISH_FROM 0, __PHISH_FROM2 0,
__PHISH_SPEAR_STRUCTURE_1 0, __SANE_MSGID 0, __SUBJ_ALPHA_END 0,
__SUBJ_ALPHA_NEGATE 0, __TO_MALFORMED_2 0, __URI_NS ,

Sender: MQSeries List <MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org>
In-Reply-To: <8127564809727966.WA.mqthelittlelife.com-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org>
Precedence: list
List-Help: <http://listserv.meduniwien.ac.at/cgi-bin/wa?LIST=MQSERIES>,
<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?body=INFO%20MQSERIES>
List-Unsubscribe: <mailto:MQSERIES-unsubscribe-request-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org>
List-Subscribe: <mailto:MQSERIES-subscribe-request-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org>
List-Owner: <mailto:MQSERIES-request-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org>
List-Archive: <http://listserv.meduniwien.ac.at/cgi-bin/wa?LIST=MQSERIES>
Archived-At: <http://permalink.gmane.org/gmane.network.mq.devel/17980>

Hi Chad,

Are you saying that, via trace, you have confirmed that an application
issuing a browse say MQGMO_BROWSE_NEXT has somehow morphed itself into a
full destructive MQGET by the time it hits the Queue Manager ? If so I would
say this is less 'interesting' and more 'worrying'. Of course it would be
possible to achieve this kind of behaviour if you had an API exit, but then
who would write an exit which did that ?

Is it possible that the destructive get is on a different queue or the
programs are are not doing quite what you were thinking they would ? If you
are certain that you have a case where an application browse is changing to
a destructive get then I would have thought contacting service with the
relevant trace files would be a priority.

Cheers,
Paul.

Paul Clarke
www.mqgem.com
-----Original Message-----
From: Chad Little
Sent: Monday, July 21, 2014 2:18 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Browse issued turns into destructive get

I have noticed an interesting behavior lately with MQ 7.5, specifically on
RHEL. Similar configuration exists on 7.1 queue managers on other operating
systems but I am not pinning this to 7.5 necessarily.

The same result has happened with two programs. One is a monitoring product
and the other is Paul's q program (V 6.0).

Using the -i (lowercase eye) for browse, the API call generated in the queue
manager is a destructive get. The requirement is some users should only
have browse access. As such +dsp, +inq, and +browse were given to the queue
along with +connect, +dsp, and +inq to the queue manager. When the user
issues q with the -i, they receive a 2035 and a trace validates that the
call they are not authorized for is +get on the queue object.

Anybody have any idea how/why a browse issued would turn into a destructive
get?

Thanks.
Chad

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES

Neil Casey

2014-07-21 06:26:19 UTC

Permalink

Hi Chad,

I tried this out on IBM MQ 8, using amqsbcg (which works) and q version 6.0.0.0 (which fails).

Looking at the traces, amqsbcg opens the queue with open_options 08000000 (little-endian) which is Browse.

However, q tries to open the queue with open_options 0a200000 (little-endian again) which is FailIfQuiescing, Browse, InputShared.

So it looks to me like q has an issue when running with very lowly authorised users, because it asks for more authority on the open than it actually needs in order to process the -i option.

Even though the subsequent code does not perform a destructive get, MQ blocks the OPEN call, so the program fails.

I have seen similar problems with BMC QMM and some other monitoring products.

Regards,

Neil
--
Neil Casey
Senior Consultant | Syntegrity Solutions

+61 414 615 334 neil.casey-VLLIzlmz+***@public.gmane.org
Syntegrity Solutions Pty Ltd | Level 23 | 40 City Road | Southgate | VIC 3006
Analyse >> Integrate >> Secure >> Educate

Post by Paul Clarke
Hi Chad,
Are you saying that, via trace, you have confirmed that an application issuing a browse say MQGMO_BROWSE_NEXT has somehow morphed itself into a full destructive MQGET by the time it hits the Queue Manager ? If so I would say this is less 'interesting' and more 'worrying'. Of course it would be possible to achieve this kind of behaviour if you had an API exit, but then who would write an exit which did that ?
Is it possible that the destructive get is on a different queue or the programs are are not doing quite what you were thinking they would ? If you are certain that you have a case where an application browse is changing to a destructive get then I would have thought contacting service with the relevant trace files would be a priority.
Cheers,
Paul.
Paul Clarke
www.mqgem.com
-----Original Message----- From: Chad Little
Sent: Monday, July 21, 2014 2:18 AM
Subject: Browse issued turns into destructive get
I have noticed an interesting behavior lately with MQ 7.5, specifically on RHEL. Similar configuration exists on 7.1 queue managers on other operating systems but I am not pinning this to 7.5 necessarily.
The same result has happened with two programs. One is a monitoring product and the other is Paul's q program (V 6.0).
Using the -i (lowercase eye) for browse, the API call generated in the queue manager is a destructive get. The requirement is some users should only have browse access. As such +dsp, +inq, and +browse were given to the queue along with +connect, +dsp, and +inq to the queue manager. When the user issues q with the -i, they receive a 2035 and a trace validates that the call they are not authorized for is +get on the queue object.
Anybody have any idea how/why a browse issued would turn into a destructive get?
Thanks.
Chad
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

Tim Zielke

2014-07-21 12:59:27 UTC

Permalink

Hi Chad,

If you are able to recreate this apparent behavior of the browse being turned into a destructive get, I would investigate it with a strmqtrc. Even if an API exit is in the mix here, the MQGET >> in the trace will show you the GMO options that are being passed in after the API exit was invoked. So you can at least see if an API exit was invoked and if it did alter any of the GMO options.

Here is an example where I did a "strmqtrc -m qmgr -t all -p amqsget" with an amqsget that is using the sample API exit amqsaxe.

07:42:50.302964 23897.1 CONN:1400006 { MQGET
07:42:50.302969 23897.1 CONN:1400006 -{ zstMQGET
07:42:50.302971 23897.1 CONN:1400006 --{ zstGetPCD
07:42:50.302972 23897.1 CONN:1400006 ---{ zstVerifyPCD
07:42:50.302974 23897.1 CONN:1400006 ---} zstVerifyPCD rc=OK FunctionTime=2
07:42:50.302975 23897.1 CONN:1400006 --} zstGetPCD rc=OK FunctionTime=4
07:42:50.302978 23897.1 CONN:1400006 --{ zutCallApiExitsBeforeGet
07:42:50.302980 23897.1 CONN:1400006 ---{ APIExit
07:42:50.302983 23897.1 CONN:1400006 ApiExit->Name:SampleApiExit ExitReason:1, Function:10
07:42:50.303014 23897.1 CONN:1400006 CompCode:0 Reason:0 ExitResponse:0 ExitResponse2:0
07:42:50.303016 23897.1 CONN:1400006 ---} APIExit rc=OK FunctionTime=36
07:42:50.303018 23897.1 CONN:1400006 ExitParms.ExitPDArea
07:42:50.303020 23897.1 CONN:1400006 0x0000: 20202020 20202020 20202020 20202020 | |
07:42:50.303020 23897.1 CONN:1400006 0x0010: 20202020 20202020 20202020 20202020 | |
07:42:50.303020 23897.1 CONN:1400006 0x0020: 20202020 20202020 20202020 20202020 | |
07:42:50.303023 23897.1 CONN:1400006 --} zutCallApiExitsBeforeGet rc=OK FunctionTime=45
07:42:50.303029 23897.1 CONN:1400006 --{ zstMQGET_CheckParms
07:42:50.303032 23897.1 CONN:1400006 --} zstMQGET_CheckParms rc=OK FunctionTime=3
07:42:50.303036 23897.1 CONN:1400006 MQGET from hObj:2 ObjectType:1 ObjectName:TCZ.TEST1: ResObjName:TCZ.TEST1:
07:42:50.303038 23897.1 CONN:1400006 __________
07:42:50.303039 23897.1 CONN:1400006 MQGET >>
07:42:50.303040 23897.1 CONN:1400006 Hconn:
07:42:50.303042 23897.1 CONN:1400006 0x0000: 06004001 |***@. |
07:42:50.303043 23897.1 CONN:1400006 Hobj:
07:42:50.303044 23897.1 CONN:1400006 0x0000: 02000000 |.... |
07:42:50.303048 23897.1 CONN:1400006 ObjHdl:2 ObjType:QUEUE ObjName:TCZ.TEST1 ResObjName:TCZ.TEST1
07:42:50.303049 23897.1 CONN:1400006 Msgdesc:
07:42:50.303051 23897.1 CONN:1400006 0x0000: 4d442020 01000000 00000000 08000000 |MD ............|
07:42:50.303051 23897.1 CONN:1400006 0x0010: ffffffff 00000000 22020000 00000000 |........".......|
07:42:50.303051 23897.1 CONN:1400006 0x0020: 20202020 20202020 ffffffff 02000000 | ........|
07:42:50.303051 23897.1 CONN:1400006 0x0030: 00000000 00000000 00000000 00000000 |................|
07:42:50.303051 23897.1 CONN:1400006 0x0040: === Skipping 16 Duplicate Lines === |................|
07:42:50.303051 23897.1 CONN:1400006 0x0140: 00000000 |.... |
07:42:50.303052 23897.1 CONN:1400006 Getmsgopts:
07:42:50.303054 23897.1 CONN:1400006 0x0000: 474d4f20 01000000 05400000 983a0000 |GMO ***@...:..|
07:42:50.303054 23897.1 CONN:1400006 0x0010: 00000000 00000000 00000000 00000000 |................|
07:42:50.303054 23897.1 CONN:1400006 0x0020: 00000000 00000000 00000000 00000000 |................|
07:42:50.303054 23897.1 CONN:1400006 0x0030: 00000000 00000000 00000000 00000000 |................|
07:42:50.303054 23897.1 CONN:1400006 0x0040: 00000000 00000000 |........ |
07:42:50.303055 23897.1 CONN:1400006 Bufferlength:
07:42:50.303056 23897.1 CONN:1400006 0x0000: ffff0000 |.... |
07:42:50.303058 23897.1 CONN:1400006 Bufferaddress:
07:42:50.303059 23897.1 CONN:1400006 0x0000: 5020baa5 ff7f0000 |P ...... |
07:42:50.303060 23897.1 CONN:1400006 Datalength : Output Parm
07:42:50.303061 23897.1 CONN:1400006 Compcode : Output Parm
07:42:50.303063 23897.1 CONN:1400006 Reason : Output Parm

You can see the API exit amqsaxe is invoked before the trace writes out the inputs into the MQGET >>.

Also, since you are on Linux, you can use the MH06 supportpac to help with the reading of the trace. Here is what the Getmsgopts in the above MQGET would get expanded to with the mqtrcfrmt program.

07:42:50.303052 23897.1 CONN:1400006 Getmsgopts:
07:42:50.303054 23897.1 CONN:1400006 0x0000: 474d4f20 01000000 05400000 983a0000 |GMO ***@...:..|
07:42:50.303054 23897.1 CONN:1400006 0x0010: 00000000 00000000 00000000 00000000 |................|
07:42:50.303054 23897.1 CONN:1400006 0x0020: 00000000 00000000 00000000 00000000 |................|
07:42:50.303054 23897.1 CONN:1400006 0x0030: 00000000 00000000 00000000 00000000 |................|
07:42:50.303054 23897.1 CONN:1400006 0x0040: 00000000 00000000 |........ |
23897.1 Getmsgopts expanded (all fields):
23897.1 StrucId (CHAR4) : 'GMO '
23897.1 x'474d4f20'
23897.1 Version (MQLONG) : 1
23897.1 x'01000000'
23897.1 MQGMO.Options= (MQLONG) : 16389
23897.1 x'05400000'
23897.1 Options=MQGMO_WAIT
23897.1 Options=MQGMO_NO_SYNCPOINT
23897.1 Options=MQGMO_CONVERT
23897.1 WaitInterval (MQLONG) : 15000
23897.1 x'983a0000'
23897.1 Signal1 (MQLONG) : 0
23897.1 x'00000000'
23897.1 Signal2 (MQLONG) : 0
23897.1 x'00000000'
23897.1 ResolvedQName (MQCHAR48) : '................................................'
23897.1 x'000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000'

Thanks,
Tim

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Neil Casey
Sent: Monday, July 21, 2014 1:26 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Browse issued turns into destructive get

Hi Chad,

I tried this out on IBM MQ 8, using amqsbcg (which works) and 'q' version 6.0.0.0 (which fails).

Looking at the traces, amqsbcg opens the queue with open_options 08000000 (little-endian) which is 'Browse'.

However, 'q' tries to open the queue with open_options 0a200000 (little-endian again) which is FailIfQuiescing, Browse, InputShared.

So it looks to me like 'q' has an issue when running with very lowly authorised users, because it asks for more authority on the open than it actually needs in order to process the -i option.

Even though the subsequent code does not perform a destructive get, MQ blocks the OPEN call, so the program fails.

I have seen similar problems with BMC QMM and some other monitoring products.

Regards,

Neil

--
Neil Casey
Senior Consultant | Syntegrity Solutions

[cid:image001.jpg-cxGyforvKAraOtW8r+xW/***@public.gmane.org] +61 414 615 334<tel:+61%20414%20615%20334>[cid:image002.jpg-cxGyforvKAraOtW8r+xW/***@public.gmane.org] neil.casey-VLLIzlmz+***@public.gmane.org <mailto:neil.casey-VLLIzlmz+***@public.gmane.org>
Syntegrity Solutions Pty Ltd<http://www.syntegrity.com.au/> | Level 23 | 40 City Road | Southgate | VIC 3006
Analyse >> Integrate >> Secure >> Educate

[cid:image003.png-cxGyforvKAraOtW8r+xW/***@public.gmane.org]

On 21 Jul 2014, at 3:03 pm, Paul Clarke <paul.clarke85-C2P5NI4ZpDVm9/***@public.gmane.org<mailto:paul.clarke85-C2P5NI4ZpDVm9/***@public.gmane.org>> wrote:

Hi Chad,

Are you saying that, via trace, you have confirmed that an application issuing a browse say MQGMO_BROWSE_NEXT has somehow morphed itself into a full destructive MQGET by the time it hits the Queue Manager ? If so I would say this is less 'interesting' and more 'worrying'. Of course it would be possible to achieve this kind of behaviour if you had an API exit, but then who would write an exit which did that ?

Is it possible that the destructive get is on a different queue or the programs are are not doing quite what you were thinking they would ? If you are certain that you have a case where an application browse is changing to a destructive get then I would have thought contacting service with the relevant trace files would be a priority.

Cheers,
Paul.

Paul Clarke
www.mqgem.com<http://www.mqgem.com>
-----Original Message----- From: Chad Little
Sent: Monday, July 21, 2014 2:18 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Browse issued turns into destructive get

I have noticed an interesting behavior lately with MQ 7.5, specifically on RHEL. Similar configuration exists on 7.1 queue managers on other operating systems but I am not pinning this to 7.5 necessarily.

The same result has happened with two programs. One is a monitoring product and the other is Paul's q program (V 6.0).

Using the -i (lowercase eye) for browse, the API call generated in the queue manager is a destructive get. The requirement is some users should only have browse access. As such +dsp, +inq, and +browse were given to the queue along with +connect, +dsp, and +inq to the queue manager. When the user issues q with the -i, they receive a 2035 and a trace validates that the call they are not authorized for is +get on the queue object.

Anybody have any idea how/why a browse issued would turn into a destructive get?

Thanks.
Chad

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT> and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT> and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

Roger Lacroix

2014-07-21 15:54:23 UTC

Permalink

Hi Neil,

Post by Tim Zielke
However, 'q' tries to open the queue with open_options 0a200000

(little-endian again) which is FailIfQuiescing, Browse, InputShared.

Post by Tim Zielke
So it looks to me like 'q' has an issue when running with very

lowly authorised users, because it asks for more authority on the
open than it actually needs in order to process the -i option.

What extra authority? OAM have never heard of the OAM checking for
permission if the application uses FailIfQuiescing and/or InputShared.

Post by Tim Zielke
they receive a 2035 and a trace validates that the call they are

not authorized for is +get on the queue object.

To me, that sounds like a bug in either the queue manager or OAM. I
would say that an 'if' statement in the MQ's code is messed up.

I would open a PMR and give IBM Support the trace file.

Regards,
Roger Lacroix
Capitalware Inc.

Post by Tim Zielke
Hi Chad,
I tried this out on IBM MQ 8, using amqsbcg (which works) and 'q'
version 6.0.0.0 (which fails).
Looking at the traces, amqsbcg opens the queue with open_options
08000000 (little-endian) which is 'Browse'.
However, 'q' tries to open the queue with open_options 0a200000
(little-endian again) which is FailIfQuiescing, Browse, InputShared.
So it looks to me like 'q' has an issue when running with very lowly
authorised users, because it asks for more authority on the open
than it actually needs in order to process the -i option.
Even though the subsequent code does not perform a destructive get,
MQ blocks the OPEN call, so the program fails.
I have seen similar problems with BMC QMM and some other monitoring products.
Regards,
Neil
--
Neil Casey
Senior Consultant | Syntegrity Solutions
[]
<tel:+61%20414%20615%20334>+61 414 615 334
[]
<http://www.syntegrity.com.au/>Syntegrity Solutions Pty Ltd | Level
23 | 40 City Road | Southgate | VIC 3006
Analyse >> Integrate >> Secure >> Educate
[]
On 21 Jul 2014, at 3:03 pm, Paul Clarke

Post by Paul Clarke
Hi Chad,
Are you saying that, via trace, you have confirmed that an
application issuing a browse say MQGMO_BROWSE_NEXT has somehow
morphed itself into a full destructive MQGET by the time it hits
the Queue Manager ? If so I would say this is less 'interesting'
and more 'worrying'. Of course it would be possible to achieve this
kind of behaviour if you had an API exit, but then who would write
an exit which did that ?
Is it possible that the destructive get is on a different queue or
the programs are are not doing quite what you were thinking they
would ? If you are certain that you have a case where an
application browse is changing to a destructive get then I would
have thought contacting service with the relevant trace files would
be a priority.
Cheers,
Paul.
Paul Clarke
<http://www.mqgem.com>www.mqgem.com
-----Original Message----- From: Chad Little
Sent: Monday, July 21, 2014 2:18 AM
Subject: Browse issued turns into destructive get
I have noticed an interesting behavior lately with MQ 7.5,
specifically on RHEL. Similar configuration exists on 7.1 queue
managers on other operating systems but I am not pinning this to
7.5 necessarily.
The same result has happened with two programs. One is a
monitoring product and the other is Paul's q program (V 6.0).
Using the -i (lowercase eye) for browse, the API call generated in
the queue manager is a destructive get. The requirement is some
users should only have browse access. As such +dsp, +inq, and
+browse were given to the queue along with +connect, +dsp, and +inq
to the queue manager. When the user issues q with the -i, they
receive a 2035 and a trace validates that the call they are not
authorized for is +get on the queue object.
Anybody have any idea how/why a browse issued would turn into a destructive get?
Thanks.
Chad
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

----------
<http://listserv.meduniwien.ac.at/archives/mqser-l.html>List Archive
-
<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1>Manage
Your List Settings -
Instructions for managing your mailing list subscription are
provided in the Listserv General Users Guide available at
<http://www.lsoft.com/resources/manuals.asp>http://www.lsoft.com

Neil Casey

2014-07-21 21:39:59 UTC

Permalink

Hi Roger,

I used shortened names for the options, to try to save some typing, and perhaps this led to some confusion.

In the trace I collected, the open options field included the bit mapping to MQOO_INPUT_SHARED. This bit indicates that the handle has to support subsequent MQGET operations. Since the user does not have permission to perform destructive MQGETs, the MQOPEN fails with 2035, which is the correct response.

MQ checks permissions at MQOPEN time (except for MQPUT1) so it cant wait to see whether an MQGET is actually issued or not.

Regards,

Neil
--
Neil Casey
Senior Consultant | Syntegrity Solutions

+61 414 615 334 neil.casey-VLLIzlmz+***@public.gmane.org
Syntegrity Solutions Pty Ltd | Level 23 | 40 City Road | Southgate | VIC 3006
Analyse >> Integrate >> Secure >> Educate

Post by Roger Lacroix
Hi Neil,

Post by Neil Casey
However, q tries to open the queue with open_options 0a200000 (little-endian again) which is FailIfQuiescing, Browse, InputShared.
So it looks to me like q has an issue when running with very lowly authorised users, because it asks for more authority on the open than it actually needs in order to process the -i option.

What extra authority? OAM have never heard of the OAM checking for permission if the application uses FailIfQuiescing and/or InputShared.

Post by Neil Casey
they receive a 2035 and a trace validates that the call they are not authorized for is +get on the queue object.

To me, that sounds like a bug in either the queue manager or OAM. I would say that an 'if' statement in the MQ's code is messed up.
I would open a PMR and give IBM Support the trace file.
Regards,
Roger Lacroix
Capitalware Inc.

Post by Neil Casey
Hi Chad,
I tried this out on IBM MQ 8, using amqsbcg (which works) and q version 6.0.0.0 (which fails).
Looking at the traces, amqsbcg opens the queue with open_options 08000000 (little-endian) which is Browse.
However, q tries to open the queue with open_options 0a200000 (little-endian again) which is FailIfQuiescing, Browse, InputShared.
So it looks to me like q has an issue when running with very lowly authorised users, because it asks for more authority on the open than it actually needs in order to process the -i option.
Even though the subsequent code does not perform a destructive get, MQ blocks the OPEN call, so the program fails.
I have seen similar problems with BMC QMM and some other monitoring products.
Regards,
Neil
--
Neil Casey
Senior Consultant | Syntegrity Solutions
Syntegrity Solutions Pty Ltd | Level 23 | 40 City Road | Southgate | VIC 3006
Analyse >> Integrate >> Secure >> Educate

List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com

Roger Lacroix

2014-07-21 22:58:06 UTC

Permalink

Hi Neil,

Post by Neil Casey
This bit indicates that the handle has to support subsequent MQGET

operations.

I think you are reading too much into that sentence. It does not say
destructive MQGET. It says MQGET which could be a destructive MQGET
or a non-destructive MQGET (browse).

I have never heard or read that using MQOO_INPUT_SHARED on an MQOPEN
implies that at least one future MQGET will be destructive.

Secondly, the default is MQOO_INPUT_AS_Q_DEF for MQOPEN and if the
queue attribute of 'DEFSOPT' (Default Input Open Option) is SHARED
(which is the default) then you have the same result.

Your logic does not make sense or else you are saying that there is a
security hole (i.e. back-door).

So, by your logic, if the user/group has 'browse' (non-destructive
MQGET) permission, since, as you said, permissions are checked at
MQOPEN, then the user can happily issue destructive MQGETs if the
application uses MQOO_INPUT_AS_Q_DEF and the queue's 'DEFSOPT'
attribute is set to SHARED because permissions were checked for the
MQOPEN and it passed.

(1) Apply +dsp, +inq, and +browse to a queue
(2) Comment out the following line from amqsbcg: GetMsgOpts.Options
+= MQGMO_BROWSE_NEXT ;
(3) Then rebuild amqsbcg and by your logic (permissions are checked
at MQOPEN), it will remove all messages from the queue even though it
does not have permission.

Pre WMQ v7 days, I was always told that permissions are checked for
MQCONN/X, MQOPEN, MQGET, MQPUT/1 and MQCLOSE (deleting of a queue)
and then cached for future use (until the refresh security command is issued).

Regards,
Roger Lacroix
Capitalware Inc.

Post by Neil Casey
Hi Roger,
I used shortened names for the options, to try to save some typing,
and perhaps this led to some confusion.
In the trace I collected, the open options field included the bit
mapping to MQOO_INPUT_SHARED. This bit indicates that the handle has
to support subsequent MQGET operations. Since the user does not have
permission to perform destructive MQGETs, the MQOPEN fails with
2035, which is the correct response.
MQ checks permissions at MQOPEN time (except for MQPUT1) so it can't
wait to see whether an MQGET is actually issued or not.
Regards,
Neil
--
Neil Casey
Senior Consultant | Syntegrity Solutions
[]
<tel:+61%20414%20615%20334>+61 414 615 334
[]
<http://www.syntegrity.com.au/>Syntegrity Solutions Pty Ltd | Level
23 | 40 City Road | Southgate | VIC 3006
Analyse >> Integrate >> Secure >> Educate
[]
On 22 Jul 2014, at 1:54 am, Roger Lacroix

Post by Roger Lacroix
Hi Neil,

Post by Tim Zielke
However, 'q' tries to open the queue with open_options 0a200000

(little-endian again) which is FailIfQuiescing, Browse, InputShared.

Post by Tim Zielke
So it looks to me like 'q' has an issue when running with very

lowly authorised users, because it asks for more authority on the
open than it actually needs in order to process the -i option.
What extra authority? OAM have never heard of the OAM checking
for permission if the application uses FailIfQuiescing and/or InputShared.

Post by Tim Zielke
they receive a 2035 and a trace validates that the call they are

not authorized for is +get on the queue object.
To me, that sounds like a bug in either the queue manager or
OAM. I would say that an 'if' statement in the MQ's code is messed up.
I would open a PMR and give IBM Support the trace file.
Regards,
Roger Lacroix
Capitalware Inc.

Post by Tim Zielke
Hi Chad,
I tried this out on IBM MQ 8, using amqsbcg (which works) and 'q'
version 6.0.0.0 (which fails).
Looking at the traces, amqsbcg opens the queue with open_options
08000000 (little-endian) which is 'Browse'.
However, 'q' tries to open the queue with open_options 0a200000
(little-endian again) which is FailIfQuiescing, Browse, InputShared.
So it looks to me like 'q' has an issue when running with very
lowly authorised users, because it asks for more authority on the
open than it actually needs in order to process the -i option.
Even though the subsequent code does not perform a destructive
get, MQ blocks the OPEN call, so the program fails.
I have seen similar problems with BMC QMM and some other
monitoring products.
Regards,
Neil
--
Neil Casey
Senior Consultant | Syntegrity Solutions
<395042.jpg> <tel:+61%20414%20615%20334>+61 414 615 334
<http://www.syntegrity.com.au/>Syntegrity Solutions Pty Ltd |
Level 23 | 40 City Road | Southgate | VIC 3006
Analyse >> Integrate >> Secure >> Educate
[]
On 21 Jul 2014, at 3:03 pm, Paul Clarke

Post by Paul Clarke
Hi Chad,
Are you saying that, via trace, you have confirmed that an
application issuing a browse say MQGMO_BROWSE_NEXT has somehow
morphed itself into a full destructive MQGET by the time it hits
the Queue Manager ? If so I would say this is less 'interesting'
and more 'worrying'. Of course it would be possible to achieve
this kind of behaviour if you had an API exit, but then who would
write an exit which did that ?
Is it possible that the destructive get is on a different queue
or the programs are are not doing quite what you were thinking
they would ? If you are certain that you have a case where an
application browse is changing to a destructive get then I would
have thought contacting service with the relevant trace files
would be a priority.
Cheers,
Paul.
Paul Clarke
<http://www.mqgem.com/>www.mqgem.com
-----Original Message----- From: Chad Little
Sent: Monday, July 21, 2014 2:18 AM
Subject: Browse issued turns into destructive get
I have noticed an interesting behavior lately with MQ 7.5,
specifically on RHEL. Similar configuration exists on 7.1 queue
managers on other operating systems but I am not pinning this to
7.5 necessarily.
The same result has happened with two programs. One is a
monitoring product and the other is Paul's q program (V 6.0).
Using the -i (lowercase eye) for browse, the API call generated
in the queue manager is a destructive get. The requirement is
some users should only have browse access. As such +dsp, +inq,
and +browse were given to the queue along with +connect, +dsp,
and +inq to the queue manager. When the user issues q with the
-i, they receive a 2035 and a trace validates that the call they
are not authorized for is +get on the queue object.
Anybody have any idea how/why a browse issued would turn into a destructive get?
Thanks.
Chad
To unsubscribe, write to
and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
To unsubscribe, write to
and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

----------
<http://listserv.meduniwien.ac.at/archives/mqser-l.html>List
Archive -
<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1>Manage
Your List Settings -
Instructions for managing your mailing list subscription are
provided in the Listserv General Users Guide available at
<http://www.lsoft.com/resources/manuals.asp>http://www.lsoft.com

Neil Casey

2014-07-22 00:05:07 UTC

Permalink

Hi Roger,

I think you need to review the documentation about when authorisation checks are applied.

According to 'http://www-01.ibm.com/support/knowledgecenter/api/content/SSFKSJ_8.0.0/com.ibm.mq.sec.doc/q010410_.htm' the check occurs at MQOPEN. The check is based on the open options.

MQOO_BROWSE requests non-destructive MQGET access. To request access to perform destructive MQGET, one of the 3 MQOO_INPUT* options must be included. The auth check happens at open time. The API is then able to enforce that a destructive MQGET cannot be performed using that handle without having to perform another auth check via the OAM. This limits the number of times that OAM is called.

So from the trace I ran, I can see that 'q' is requesting permission to perform destructive MQGET using the handle to the queue, even when -i (lower case) is used. The actual MQGET is for browse, but if your user isn't permitted to GET destructively, MQ correctly rejects the MQOPEN.

This looks like a (minor) bug in 'q', not a major bug in MQ.

Regards,

Neil

Sent from my iPad

Post by Roger Lacroix
Hi Neil,

Post by Neil Casey
This bit indicates that the handle has to support subsequent MQGET operations.

I think you are reading too much into that sentence. It does not say destructive MQGET. It says MQGET which could be a destructive MQGET or a non-destructive MQGET (browse).
I have never heard or read that using MQOO_INPUT_SHARED on an MQOPEN implies that at least one future MQGET will be destructive.
Secondly, the default is MQOO_INPUT_AS_Q_DEF for MQOPEN and if the queue attribute of 'DEFSOPT' (Default Input Open Option) is SHARED (which is the default) then you have the same result.
Your logic does not make sense or else you are saying that there is a security hole (i.e. back-door).
So, by your logic, if the user/group has 'browse' (non-destructive MQGET) permission, since, as you said, permissions are checked at MQOPEN, then the user can happily issue destructive MQGETs if the application uses MQOO_INPUT_AS_Q_DEF and the queue's 'DEFSOPT' attribute is set to SHARED because permissions were checked for the MQOPEN and it passed.
(1) Apply +dsp, +inq, and +browse to a queue
(2) Comment out the following line from amqsbcg: GetMsgOpts.Options += MQGMO_BROWSE_NEXT ;
(3) Then rebuild amqsbcg and by your logic (permissions are checked at MQOPEN), it will remove all messages from the queue even though it does not have permission.
Pre WMQ v7 days, I was always told that permissions are checked for MQCONN/X, MQOPEN, MQGET, MQPUT/1 and MQCLOSE (deleting of a queue) and then cached for future use (until the refresh security command is issued).
Regards,
Roger Lacroix
Capitalware Inc.

Post by Neil Casey
Hi Roger,
I used shortened names for the options, to try to save some typing, and perhaps this led to some confusion.
In the trace I collected, the open options field included the bit mapping to MQOO_INPUT_SHARED. This bit indicates that the handle has to support subsequent MQGET operations. Since the user does not have permission to perform destructive MQGETs, the MQOPEN fails with 2035, which is the correct response.
MQ checks permissions at MQOPEN time (except for MQPUT1) so it canât wait to see whether an MQGET is actually issued or not.
Regards,
Neil
--
Neil Casey
Senior Consultant | Syntegrity Solutions
Syntegrity Solutions Pty Ltd | Level 23 | 40 City Road | Southgate | VIC 3006
Analyse >> Integrate >> Secure >> Educate

Post by Roger Lacroix
Hi Neil,

However, âqâ tries to open the queue with open_options 0a200000 (little-endian again) which is FailIfQuiescing, Browse, InputShared.
So it looks to me like âqâ has an issue when running with very lowly authorised users, because it asks for more authority on the open than it actually needs in order to process the -i option.

What extra authority? OAM have never heard of the OAM checking for permission if the application uses FailIfQuiescing and/or InputShared.

they receive a 2035 and a trace validates that the call they are not authorized for is +get on the queue object.

Hi Chad,
I tried this out on IBM MQ 8, using amqsbcg (which works) and âqâ version 6.0.0.0 (which fails).
Looking at the traces, amqsbcg opens the queue with open_options 08000000 (little-endian) which is âBrowseâ.
However, âqâ tries to open the queue with open_options 0a200000 (little-endian again) which is FailIfQuiescing, Browse, InputShared.
So it looks to me like âqâ has an issue when running with very lowly authorised users, because it asks for more authority on the open than it actually needs in order to process the -i option.
Even though the subsequent code does not perform a destructive get, MQ blocks the OPEN call, so the program fails.
I have seen similar problems with BMC QMM and some other monitoring products.
Regards,
Neil
--
Neil Casey
Senior Consultant | Syntegrity Solutions
Syntegrity Solutions Pty Ltd | Level 23 | 40 City Road | Southgate | VIC 3006
Analyse >> Integrate >> Secure >> Educate

List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com

Chad Little

2014-07-23 17:46:15 UTC

Permalink

Thanks to all who responded.

I agree this appears to be a bug in the calling program (q in this case) unless someone proves different.

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES

Tim Zielke

2014-07-24 12:44:14 UTC

Permalink

Hi Chad,

As far as if the q program has a bug in it, that could probably be debated. The q program's main purpose is to be a pipe line utility between 2 queues, so the designer could have went with the assumption that the user would have both browse and get access to the referenced input queues. But that is probably neither here nor there.

As far as still using the q program for your purposes where a user only has browse access to a queue, I would think that could still be done in the Unix space with the follow approach:

1. Create a locked down script that invokes the q program with just the -i option
2. Give the user sudo access to call the script with a group that does have get access to the queue

We do similar things here in the Unix space with sudo and scripts to allow users in a controlled and secure way to have access to see queue depths, turn triggering on/off, etc.

Thanks,
Tim

-----Original Message-----
From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Chad Little
Sent: Wednesday, July 23, 2014 12:46 PM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: Browse issued turns into destructive get

Thanks to all who responded.

I agree this appears to be a bug in the calling program (q in this case) unless someone proves different.

To unsubscribe, write to ***@LISTSERV.MEDUNIWIEN.AC.AT and, in the message body (not the subject), write: SIGNOFF MQSERIES Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

To unsubscribe, write to ***@LISTSERV.MEDUNIWIEN.AC.AT and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: ht