| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| RACLIST the MQ classes? |
« View previous topic :: View next topic » |
| Author |
Message
|
| PeterPotkay |
 Posted: Tue May 11, 2010 4:30 pm Post subject: RACLIST the MQ classes? |
 |
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Do you RACLIST your RACF MQ classes? My RACF guy said we should RACLIST them if the MQ manuals say to, but I don't see anything about that.
http://publib.boulder.ibm.com/infocenter/wmqv7/v7r0/topic/com.ibm.mq.csqsav.doc/zs12100_.htm
So I guess that implies the MQ classes do not need to be RACLISTed, correct? Any harm if they are?
We are not experiencing any MQ related performance problems, but are in the middle of enable RACF MQ security.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Wed May 12, 2010 5:22 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
|
| Back to top |
|
|
| zpat |
| Posted: Wed May 12, 2010 5:35 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
It's a trade off between reducing I/O to the RACF Database and having to manually refresh the RACLISTed classes when the profiles change.
When I was a RACF sysprog, I raclisted most classes but also had an automatic raclist refresh performed every hour.
It depends how often they are accessed and how often they get changed.
If they are accessed frequently or changed infrequently - raclist them.
Last edited by zpat on Wed May 12, 2010 5:52 am; edited 1 time in total |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed May 12, 2010 5:47 am Post subject: Re: RACLIST the MQ classes? |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| PeterPotkay wrote: |
| Do you RACLIST your RACF MQ classes? |
FWIW we don't
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed May 12, 2010 5:55 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| It's a trade off between reducing I/O to the RACF Database and having to manually refresh the RACLISTed classes when the profiles change. |
Given that RACF profiles don't change all much, and lots of z resources (horsepower, channel bandwidth, central storage), the trade-off is marginal at best.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| zpat |
| Posted: Wed May 12, 2010 6:16 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Having them in storage will reduce the latency (i.e. improve the speed) of RACHECK (RACROUTE TYPE=AUTH) calls made by MQ.
However some z/OS subsystems perform their own RACLIST in their own address space by using the appropriate RACLIST (RACROUTE TYPE=LIST) call, in which case you don't need to use the command version.
You can tell if a subsystem is doing this, if there is a need to issue a refresh command to the subsystem to make changes take effect.
Last edited by zpat on Wed May 12, 2010 6:20 am; edited 1 time in total |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed May 12, 2010 6:18 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
http://publib.boulder.ibm.com/infocenter/zos/v1r9/index.jsp?topic=/com.ibm.zos.r9.icha200/raclist.htm
| Quote: |
Before you use RACLIST, consider how frequently the class is referenced, the number of profiles in the class, and the amount of storage that would be required to hold the profiles. Use SETROPTS RACLIST when the general resource class contains frequently referenced profiles, and global access checking cannot be used (that is, everyone is not allowed access to the resources).
|
Does the QM access the RACF profiles once at QM start up (or REFRESH SECURITY), or is it accessing them for every MQOPEN, MQPUT, MEGET, MQCONN, etc.?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| zpat |
| Posted: Wed May 12, 2010 6:22 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
See my post above, if there is a refresh security option for MQ on z/OS then it is almost certainly doing it's own RACLIST into storage.
This allows the RACHECK calls to work normally, but the SAF will use the instorage profiles, rather than performing i/o to the RACF database. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed May 12, 2010 6:22 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
This is from my memory (foggy); and is consistent with CICS, IMS, and other subystem behavior... REFRESH drags all of the MQ-related RACF ACEEs into the MQ address space.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed May 12, 2010 6:25 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Makes sense to me. I'm going to say we don't need to RACLIST the MQ classes.
Thanks guys.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| zpat |
| Posted: Wed May 12, 2010 6:26 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
No, it's not reading all the user ACEEs into storage. Nor all the groups.
It is reading the profiles (access control lists) for a given MQ resource class into storage.
The RACHECK will be done against the ACEE of the id being checked.
SAF will match the id or one of the connect groups for that id to the ACL and return the appropriate result. |
|
| Back to top |
|
|
| IEFBR14 |
| Posted: Tue Apr 05, 2011 6:21 am Post subject: |
|
|
Newbie
Joined: 22 Jan 2010
Posts: 4
|
The MQ security related to RACLIST seems to be a little bit more complex. Well, I did not find a lot of description in the MQ manuals. I am RACF systems programmer and not MQ admin. So this can only be a personal opinion how it _might_ be.
(a) resource profiles are defined in SAF/RACF as usual, as well as access lists...so far so good (take care of the switch profiles).
(b) resource profiles are grouped into classes more or less meaningful ... ok, IBM has done this for us and I think it suits our needs well.
This was easy, now it's getting a little more tricky...
(c) MQ caches security settings, but only those with AUDIT parameter in the resource profile set to NONE. MQ just remembers SAF's answer on a RACROUTE REQUEST=AUTH call.
And now to the interesting part...
(d) Some classes may be RACLISTed (which is the wrong expression, more on this later), but in different ways: SETR RACLIST for MQCMDS or MQCONN for instance work, but for MQQUEUE, MQADMIN or MQNLIST you will gain message ICH14027I. This setting is defined in the IBM supplied static class descriptor table.
How comes, IBM allows RACLIST for some classes and others not? First of all, I did not find an answer on this topic in the MQ manuals. But I think it might be this way: There are three variants to load class profiles into storage: SETROPTS RACLIST command by security administrator or two types of RACROUTE REQUEST=LIST call by application program. The main difference is related to behaviour of subsequent RACROUTE REQUEST=FASTAUTH calls. When the class is RACLISTed using SETROPTS command, then the FASTAUTH request needs to be issued from authorized program, that is PSW in supervisor state or storage key less than 8.
Instead, FASTAUTH for "the other RACLIST" also will succeed with problem state PSW or storage key higher than 8. However, to achieve the RACROUTE,REQUEST=LIST, the program needs to have APF authorization or be included in ICHAUTAB. As far as I know, MQ has to be APF authorized and also runs in storage key 7 -- at least the queue manager as you can see in SCHEDxx PARMLIB-Member for CSQYASCP. But other components like the channel initiator are only eligible for FASTAUTH with RACROUTE REQUEST=LIST profiles but not RACLISTed.
So, in order to allow FASTCHECK, the MQ-classes in question need to be RACLISTed using RACROUTE macro and not SETROPTS command.
Now for the REFRESH:
Whenever there were changes to the resource profiles, e.g. some IDs were added to the access list, the security settings might need to be refreshed:
(a) MQ cache: The MQ refresh command just throws away the notes about SAF's answer to RACROUTE calls. If there is AUDIT in any way, you do not need to bother.
(b) RACLISTed classes: for changes on profiles of a class RACLISTed with SETROPTS command, the security administrator will see message ICH06011I indicating the need for refresh. For classes loaded into storage with RACROUTE REQUEST=LIST, the security admin will not see that message. In both cases the changes will become active not before RACF command SETROPTS RACLIST(class) REFRESH.
Remember I was writing about _three_ ways to load RACF profiles into storage? First was RACLIST with SETROPTS command as described above. The other way RACROUTE REQUEST=LIST can be coded with GLOBAL=YES or GLOBAL=NO. The difference is, that by using GLOBAL=NO an ASID will get its private copy of RACF information. In contrast, with GLOBAL=YES a data space is created for general use by all ASIDs. Obviously, a private copy made with GLOBAL=NO cannot be refreshed by SETROPTS RACLIST(class) REFRESH or other means except from the owning ASID in question.
So, if MQ called RACROUTE REQUEST=LIST,GLOBAL=NO, the security administrator would not have a chance to refresh. Instead, the MQ administrator would do so. But I did not find any hint about such behaviour in the MQ manuals.
Conclusion:
* Classes MQCMDS and MQCONN may be RACLISTED using SETROPTS --> no hassle.
* Classes MQQUEUE, MQADMIN and MQNLIST seem to be loaded into data spaces with RACROUTE REQUEST=LIST,GLOBAL=YES on demand -- by the MQ program (propably because it needs this for RACROUTE REQUEST=FASTAUTH with PSW in problem state).
--> In other words: the IBM supplied static class descriptor table regulates whether you may RACLIST the class or not
* Changing profiles or authorities results in sequence of SETROPTS RACLIST REFRESH for all classes followed by MQ REFRESH command in case AUDIT is not set. |
|
| 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
|
|
|
|
