Checking MQ and MCAUSER permissions on Linux

I want to check all the permissions and access levels for queues and channels in my MQ manager and check if there is a client queue or a channel with administrative access. I used the command for this ./dmpmqaut

and I have successfully reset all object permissions. However, I have two problems:

1 In my Q-manager has a lot of objects that have an object mqm

, and their powers are set to: almqi dlt chg dsp clr

. So is this okay? I mean, all I know is that clients are not supposed to have an mqm

entity name, and the permissions are not limited here at all. I'm right?

2- I want to check all channels and queues MCAUSER

like what I see in MQ-Explorer on windows. Is there a way to test this on a Linux machine?


source to share

1 answer

Whenever an MQ object is created, the user who created it (or this primary user group on non-Windows distributed platforms) is granted full rights to the object. In practice, this usually means that the mqm group is visible on every object when you dump auths. On windows, this is often adminID@domain

in addition to mqm.

On Linux, you can do ...
echo "dis chl(*) mcauser | runmqsc [qmgrname]

... from the command line to see what MCAUSER is on pipes. You can also see this with MQ Explorer.

The defined MCAUSER for all incoming channels must be one that blocks all access. I recommended nobody

, but since this is a potentially valid identifier on some systems, I now recommend *nobody

. Please note that for "inbound" I mean the types RCVR




. By "all" I mean channels with the name SYSTEM.AUTO.*


and all that you define yourself.

Make sure the rule exit or CHLAUTH

match MCAUSER to the expected value when the connection request is authenticated. Rules CHLAUTH

are available in any version of MQ from 7.1 to version. This mapping ensures that only an authenticated user or QMgr partner can connect.

If authorization ( setmqaut


) commands are defined without defining rules CHLAUTH

or configuring security exit, the effect is worse, not better. The reason is that legitimate users will have restrictions on their connection, but malicious users can easily trick the administrative user ID.

For more information on this topic, see the MQ security simplification master slides at http://t-rob./net/links .



All Articles