Discussion:
SET AUTHREC - using AUTHRMV(ALL) then AUTHADD
Potkay, Peter M (CTO Architecture + Engineering)
2014-10-15 00:59:33 UTC
Permalink
http://www-01.ibm.com/support/knowledgecenter/#!/SSFKSJ_7.5.0/com.ibm.mq.ref.adm.doc/q086620_.htm

[quote]
Usage notes
The list of authorizations to add and the list of authorizations to remove must not overlap. For example, you cannot add display authority and remove display authority with the same command. This rule applies even if the authorities are expressed using different options. For example, the following command fails because DSP authority overlaps with ALLADM authority:
SET AUTHREC PROFILE(*) OBJTYPE(QUEUE) PRINCIPAL(PRINC01) AUTHADD(DSP) AUTHRMV(ALLADM)
[/quote]

OK, that's straightforward.

But I intended to replicate what I did in my setmqaut scripts where, being a T.Rob disciple, I clearly remove any and all authorities before applying what I intend, knowing that I end up with only exactly what this command says and no other leftover junk.

So I try the following command, and it works:
SET AUTHREC GROUP('mygroup') OBJTYPE(QMGR) AUTHRMV(ALL) AUTHADD(CONNECT)
And that conflicts with the Knowledge Center article, since ALL clearly overlaps CONNECT.

So is the Knowledge Center Article wrong? Or am I taking advantage of a loophole that might get "fixed" who knows when?



Peter Potkay

************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************

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
Paul Meekin
2014-10-15 09:32:28 UTC
Permalink
That's a good question. The warning not to use overlapping authorities
implies that there is no fixed order to the application of those
authorities. Do you know if you are always getting the expected outcome
with your commands?

That said, a quick scan through the KC shows that there is no documented
order to how the authorities are applied for setmqaut either! Many of us
use the "-all +whatever" form so I hope we aren't going to get bitten one
day if this gets "optimised".

As an aside I notice the KC setmqaut entry for MQ 8 still only mentions
group permissions for Unix/Linux. I'll click on the feedback link but if
anyone responsible is reading this...




From: "Potkay, Peter M (CTO Architecture + Engineering)" <***@THEHARTFORD.COM>

To: ***@LISTSERV.MEDUNIWIEN.AC.AT

Date: 15/10/2014 01:59

Subject: SET AUTHREC - using AUTHRMV(ALL) then AUTHADD

Sent by: MQSeries List <***@LISTSERV.MEDUNIWIEN.AC.AT>






http://www-01.ibm.com/support/knowledgecenter/#!/SSFKSJ_7.5.0/com.ibm.mq.ref.adm.doc/q086620_.htm

[quote]
Usage notes
The list of authorizations to add and the list of authorizations to remove
must not overlap. For example, you cannot add display authority and remove
display authority with the same command. This rule applies even if the
authorities are expressed using different options. For example, the
following command fails because DSP authority overlaps with ALLADM
authority:
SET AUTHREC PROFILE(*) OBJTYPE(QUEUE) PRINCIPAL(PRINC01) AUTHADD(DSP)
AUTHRMV(ALLADM)
[/quote]

OK, that's straightforward.

But I intended to replicate what I did in my setmqaut scripts where, being
a T.Rob disciple, I clearly remove any and all authorities before applying
what I intend, knowing that I end up with only exactly what this command
says and no other leftover junk.

So I try the following command, and it works:
SET AUTHREC GROUP('mygroup') OBJTYPE(QMGR) AUTHRMV(ALL) AUTHADD(CONNECT)
And that conflicts with the Knowledge Center article, since ALL clearly
overlaps CONNECT.

So is the Knowledge Center Article wrong? Or am I taking advantage of a
loophole that might get “fixed” who knows when?



Peter Potkay








************************************************************
HSBC Bank plc
Registered Office: 8 Canada Square, London E14 5HQ
Registered in England - Number 14259
Authorised by the Prudential Regulation Authority and regulated by the
Financial Conduct Authority and the Prudential Regulation Authority
************************************************************
-----------------------------------------
SAVE PAPER - THINK BEFORE YOU PRINT!

This E-mail is confidential.

It may also be legally privileged. If you are not the addressee you
may not copy, forward, disclose or use any part of it. If you have
received this message in error, please delete it and all copies
from your system and notify the sender immediately by return
E-mail.

Internet communications cannot be guaranteed to be timely secure,
error or virus-free. The sender does not accept liability for any
errors or omissions.

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:/
Potkay, Peter M (CTO Architecture + Engineering)
2014-10-15 11:48:25 UTC
Permalink
It seems to work the way I expect, but I'm just one guy testing one object type. No matter how many things I may have added for that group and profile before, dmpmqcfg confirms all that currently is in force is only what I put after the AUTHRMV(ALL) in the last SET AUTHREC command I ran for that object / group.

Before I bank on this and replace my setmqaut script with these SET AUTHREC commands, I need to know the AUTHRMV(ALL) can be used in all the commands along with the AUTHADDs I actually want.



Peter Potkay


-----Original Message-----
From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Paul Meekin
Sent: Wednesday, October 15, 2014 5:32 AM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: SET AUTHREC - using AUTHRMV(ALL) then AUTHADD

That's a good question. The warning not to use overlapping authorities implies that there is no fixed order to the application of those authorities. Do you know if you are always getting the expected outcome with your commands?

That said, a quick scan through the KC shows that there is no documented order to how the authorities are applied for setmqaut either! Many of us use the "-all +whatever" form so I hope we aren't going to get bitten one day if this gets "optimised".

As an aside I notice the KC setmqaut entry for MQ 8 still only mentions group permissions for Unix/Linux. I'll click on the feedback link but if anyone responsible is reading this...




From: "Potkay, Peter M (CTO Architecture + Engineering)" <***@THEHARTFORD.COM>

To: ***@LISTSERV.MEDUNIWIEN.AC.AT

Date: 15/10/2014 01:59

Subject: SET AUTHREC - using AUTHRMV(ALL) then AUTHADD

Sent by: MQSeries List <***@LISTSERV.MEDUNIWIEN.AC.AT>






http://www-01.ibm.com/support/knowledgecenter/#!/SSFKSJ_7.5.0/com.ibm.mq.ref.adm.doc/q086620_.htm

[quote]
Usage notes
The list of authorizations to add and the list of authorizations to remove must not overlap. For example, you cannot add display authority and remove display authority with the same command. This rule applies even if the authorities are expressed using different options. For example, the following command fails because DSP authority overlaps with ALLADM
authority:
SET AUTHREC PROFILE(*) OBJTYPE(QUEUE) PRINCIPAL(PRINC01) AUTHADD(DSP)
AUTHRMV(ALLADM)
[/quote]

OK, that's straightforward.

But I intended to replicate what I did in my setmqaut scripts where, being a T.Rob disciple, I clearly remove any and all authorities before applying what I intend, knowing that I end up with only exactly what this command says and no other leftover junk.

So I try the following command, and it works:
SET AUTHREC GROUP('mygroup') OBJTYPE(QMGR) AUTHRMV(ALL) AUTHADD(CONNECT) And that conflicts with the Knowledge Center article, since ALL clearly overlaps CONNECT.

So is the Knowledge Center Article wrong? Or am I taking advantage of a loophole that might get “fixed” who knows when?



Peter Potkay








************************************************************
HSBC Bank plc
Registered Office: 8 Canada Square, London E14 5HQ
Registered in England - Number 14259
Authorised by the Prudential Regulation Authority and regulated by the
Financial Conduct Authority and the Prudential Regulation Authority
************************************************************
-----------------------------------------
SAVE PAPER - THINK BEFORE YOU PRINT!

This E-mail is confidential.

It may also be legally privileged. If you are not the addressee you may not copy, forward, disclose or use any part of it. If you have received this message in error, please delete it and all copies from your system and notify the sender immediately by return
E-mail.

Internet communications cannot be guaranteed to be timely secure, error or virus-free. The sender does not accept liability for any errors or omissions.

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
************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************


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
Jefferson Lowrey
2014-10-15 12:48:00 UTC
Permalink
"So is the Knowledge Center Article wrong? Or am I taking advantage of a
loophole that might get “fixed” who knows when?"

Probably both.

Out of curiosity, does it change if you put the AUTHRMV first in the
command (i.e. before the AUTHADD)?

Thank you,

Jeff Lowrey




From: "Potkay, Peter M (CTO Architecture + Engineering)"
<***@THEHARTFORD.COM>
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Date: 10/14/2014 07:59 PM
Subject: [MQSERIES] SET AUTHREC - using AUTHRMV(ALL) then AUTHADD
Sent by: MQSeries List <***@LISTSERV.MEDUNIWIEN.AC.AT>



http://www-01.ibm.com/support/knowledgecenter/#!/SSFKSJ_7.5.0/com.ibm.mq.ref.adm.doc/q086620_.htm

[quote]
Usage notes
The list of authorizations to add and the list of authorizations to remove
must not overlap. For example, you cannot add display authority and remove
display authority with the same command. This rule applies even if the
authorities are expressed using different options. For example, the
following command fails because DSP authority overlaps with ALLADM
authority:
SET AUTHREC PROFILE(*) OBJTYPE(QUEUE) PRINCIPAL(PRINC01) AUTHADD(DSP)
AUTHRMV(ALLADM)
[/quote]

OK, that's straightforward.

But I intended to replicate what I did in my setmqaut scripts where, being
a T.Rob disciple, I clearly remove any and all authorities before applying
what I intend, knowing that I end up with only exactly what this command
says and no other leftover junk.

So I try the following command, and it works:
SET AUTHREC GROUP('mygroup') OBJTYPE(QMGR) AUTHRMV(ALL) AUTHADD(CONNECT)
And that conflicts with the Knowledge Center article, since ALL clearly
overlaps CONNECT.

So is the Knowledge Center Article wrong? Or am I taking advantage of a
loophole that might get “fixed” who knows when?



Peter Potkay

************************************************************
This communication, including attachments, is for the exclusive use of
addressee and may contain proprietary, confidential and/or privileged
information. If you are not the intended recipient, any use, copying,
disclosure, dissemination or distribution is strictly prohibited. If you
are not the intended recipient, please notify the sender immediately by
return e-mail, delete this communication and destroy all copies.
************************************************************


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


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
Potkay, Peter M (CTO Architecture + Engineering)
2014-10-15 12:54:38 UTC
Permalink
“Out of curiosity, does it change if you put the AUTHRMV first in the command (i.e. before the AUTHADD)?”
That is how I’m using it, remove all first, then add in what I want.

Morag confirmed over on mqseries.net this is working as designed and intended. The KC doc needs to be updated to let us know its acceptable to use remove all and then add in what you want on the same command.

Peter Potkay

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Jefferson Lowrey
Sent: Wednesday, October 15, 2014 8:48 AM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: SET AUTHREC - using AUTHRMV(ALL) then AUTHADD

"So is the Knowledge Center Article wrong? Or am I taking advantage of a loophole that might get “fixed” who knows when?"

Probably both.

Out of curiosity, does it change if you put the AUTHRMV first in the command (i.e. before the AUTHADD)?

Thank you,

Jeff Lowrey




From: "Potkay, Peter M (CTO Architecture + Engineering)" <***@THEHARTFORD.COM<mailto:***@THEHARTFORD.COM>>
To: ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>
Date: 10/14/2014 07:59 PM
Subject: [MQSERIES] SET AUTHREC - using AUTHRMV(ALL) then AUTHADD
Sent by: MQSeries List <***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>>
________________________________



http://www-01.ibm.com/support/knowledgecenter/#!/SSFKSJ_7.5.0/com.ibm.mq.ref.adm.doc/q086620_.htm

[quote]
Usage notes
The list of authorizations to add and the list of authorizations to remove must not overlap. For example, you cannot add display authority and remove display authority with the same command. This rule applies even if the authorities are expressed using different options. For example, the following command fails because DSP authority overlaps with ALLADM authority:
SET AUTHREC PROFILE(*) OBJTYPE(QUEUE) PRINCIPAL(PRINC01) AUTHADD(DSP) AUTHRMV(ALLADM)
[/quote]

OK, that's straightforward.

But I intended to replicate what I did in my setmqaut scripts where, being a T.Rob disciple, I clearly remove any and all authorities before applying what I intend, knowing that I end up with only exactly what this command says and no other leftover junk.

So I try the following command, and it works:
SET AUTHREC GROUP('mygroup') OBJTYPE(QMGR) AUTHRMV(ALL) AUTHADD(CONNECT)
And that conflicts with the Knowledge Center article, since ALL clearly overlaps CONNECT.

So is the Knowledge Center Article wrong? Or am I taking advantage of a loophole that might get “fixed” who knows when?



Peter Potkay


************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************



________________________________
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.MEDUNIWIEN.AC.AT?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>

________________________________
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.MEDUNIWIEN.AC.AT?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>
************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************


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
Jefferson Lowrey
2014-10-15 12:59:48 UTC
Permalink
Yes, how to tell I check my email first... ;-)

And, sorry, I was reading the example in the doc you had cited, not your
actual code.

For those curious, Morag's response is here:
http://www.mqseries.net/phpBB2/viewtopic.php?t=68669

Thank you,

Jeff Lowrey




From: "Potkay, Peter M (CTO Architecture + Engineering)"
<***@THEHARTFORD.COM>
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Date: 10/15/2014 07:54 AM
Subject: Re: [MQSERIES] SET AUTHREC - using AUTHRMV(ALL) then
AUTHADD
Sent by: MQSeries List <***@LISTSERV.MEDUNIWIEN.AC.AT>



“Out of curiosity, does it change if you put the AUTHRMV first in the
command (i.e. before the AUTHADD)?”
That is how I’m using it, remove all first, then add in what I want.

Morag confirmed over on mqseries.net this is working as designed and
intended. The KC doc needs to be updated to let us know its acceptable to
use remove all and then add in what you want on the same command.

Peter Potkay

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf
Of Jefferson Lowrey
Sent: Wednesday, October 15, 2014 8:48 AM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: SET AUTHREC - using AUTHRMV(ALL) then AUTHADD

"So is the Knowledge Center Article wrong? Or am I taking advantage of a
loophole that might get “fixed” who knows when?"

Probably both.

Out of curiosity, does it change if you put the AUTHRMV first in the
command (i.e. before the AUTHADD)?

Thank you,

Jeff Lowrey




From: "Potkay, Peter M (CTO Architecture + Engineering)" <
***@THEHARTFORD.COM>
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Date: 10/14/2014 07:59 PM
Subject: [MQSERIES] SET AUTHREC - using AUTHRMV(ALL) then AUTHADD
Sent by: MQSeries List <***@LISTSERV.MEDUNIWIEN.AC.AT>




http://www-01.ibm.com/support/knowledgecenter/#!/SSFKSJ_7.5.0/com.ibm.mq.ref.adm.doc/q086620_.htm


[quote]
Usage notes
The list of authorizations to add and the list of authorizations to remove
must not overlap. For example, you cannot add display authority and remove
display authority with the same command. This rule applies even if the
authorities are expressed using different options. For example, the
following command fails because DSP authority overlaps with ALLADM
authority:
SET AUTHREC PROFILE(*) OBJTYPE(QUEUE) PRINCIPAL(PRINC01) AUTHADD(DSP)
AUTHRMV(ALLADM)
[/quote]

OK, that's straightforward.

But I intended to replicate what I did in my setmqaut scripts where, being
a T.Rob disciple, I clearly remove any and all authorities before applying
what I intend, knowing that I end up with only exactly what this command
says and no other leftover junk.

So I try the following command, and it works:
SET AUTHREC GROUP('mygroup') OBJTYPE(QMGR) AUTHRMV(ALL) AUTHADD(CONNECT)
And that conflicts with the Knowledge Center article, since ALL clearly
overlaps CONNECT.

So is the Knowledge Center Article wrong? Or am I taking advantage of a
loophole that might get “fixed” who knows when?



Peter Potkay

************************************************************
This communication, including attachments, is for the exclusive use of
addressee and may contain proprietary, confidential and/or privileged
information. If you are not the intended recipient, any use, copying,
disclosure, dissemination or distribution is strictly prohibited. If you
are not the intended recipient, please notify the sender immediately by
return e-mail, delete this communication and destroy all copies.
************************************************************


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


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
************************************************************
This communication, including attachments, is for the exclusive use of
addressee and may contain proprietary, confidential and/or privileged
information. If you are not the intended recipient, any use, copying,
disclosure, dissemination or distribution is strictly prohibited. If you
are not the intended recipient, please notify the sender immediately by
return e-mail, delete this communication and destroy all copies.
************************************************************


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


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

Loading...