It took me a while to partially understand setmqaut and dspmqaut – and your security may be a mess.

On Linux, I was looking into MQ context security , where you can prevent a user from putting a fake information into the MQMD, and to my surprise it kept on working! It took me a while to work out what was going on.

Some of the things I learned include

• If a userid is in the mqm group, it overrides any setmqaut statements. You may want to have a group called MQADMIN, and have your administrators in that group rather than the mqm group; so they can create or alter queues , but not put messages to sensitive queues.
• Your overall access permission depends on the settings for the policy for the userid and any groups it is in. If one of your groups has permission, you have permission. If no group has permission, your userid gets no permission.
• If you add or remove userids from groups, you have to use the runmqsc command refresh security to pick up the changes.
• If you are using a userid in the mqm group to test your application – you may be testing with a different set of permissions to your target user.
• It is better to define security profiles using groups rather than userids. If someone joins the team, you just put them in the group. If security is done using userids, you have to replicate all of the definitions of an existing user. Similarly if someone leaves the team.
• The difference between group and principal (userid) is fuzzy. You define authority on a userid – but it appears as a group. Thanks to Joshm who pointed out that on Unix the qm.ini SecurityPolicy=user|group|UserExternal|default controls whether security is done with userids or groups. I need to explore this, but it explains some of my confusion
• Some of the commands, for example dmpmqaut do not work as documented, but you can work round it.
• setmqauth and dspmqauth parameters are read asis – with display authrec mixed case fields need to be surrounded with single quotes.
• If you remove permission, then check, as you may get permission from more than one group.

Controlling the ability to change the context of a message.

This facility allows an application to specify the MQMD fields PutApplType, PutApplName, PutDate and ApplOriginData, rather than have them filled in by the queue manager. An MCA channel would do this when putting a message, to keep the original information. See origin context.

The key security parmeter is “setall” which allows these fields to be set.

Being a good tester, I displayed the permissions before changing them.

dspmqaut -m QMA -n CP0000 -t queue -p colinpaice

This says display the attributes for Queue CP0000 for user colinpaice.

I also defined authorities for another userid

setmqaut -m QMA -n CP0000 -t queue -p testuser +allmqi

I could not see how to use dspmqaut to display the authorities for all users of a queue, however you can use the runqmqsc DIS AUTHREC command, dmpmqaut and dmpmqcfg -m … -x authrec to dump out the permissions for users of an object.

The documentation is a little unclear – it talks about entity without actually saying what an entity was. I assumed the entity was the queue name, it actually means userid or group – but this is not strictly true.

runmqsc dis authrec displayed

dis authrec profile(CP0000)
     3 : dis authrec profile(CP0000)

AMQ8864I: Display authority record details.
   PROFILE(CP0000)                         ENTITY(mqm)
   ENTTYPE(GROUP)                          OBJTYPE(QUEUE) 
   AUTHLIST(BROWSE,CHG,CLR,DLT,DSP,GET,INQ,PUT,
   PASSALL,PASSID,SET,SETALL,SETID)

AMQ8864I: Display authority record details.
   PROFILE(CP0000)                         ENTITY(testuser)
   ENTTYPE(GROUP)                          OBJTYPE(QUEUE)
   AUTHLIST(BROWSE,CHG,CLR,DLT,DSP,GET,INQ,PUT,PASSALL,PASSID,SET,SETALL,SETID)

AMQ8864I: Display authority record details.
   PROFILE(**)                             ENTITY(test)
   ENTTYPE(GROUP)                          OBJTYPE(TOPIC)
   AUTHLIST(DSP)
...                        

This needs a bit of explaining.

Display information about a group’s access to a profile

AMQ8864I: Display authority record details.
   PROFILE(CP0000)                         ENTITY(mqm)
   ENTTYPE(GROUP)                          OBJTYPE(QUEUE)
   AUTHLIST(BROWSE,CHG,CLR,DLT,DSP,GET,INQ,PUT,PASSALL,PASSID,SET,SETALL,SETID) 

For Object type of Queue, there is a profile for object CP0000. The profile applies to group mqm. It has lots of access. That was pretty self explanatory.

Display information about a userid’s access to a profile

AMQ8864I: Display authority record details.
   PROFILE(CP0000)                         ENTITY(testuser)
   ENTTYPE(GROUP)                          OBJTYPE(QUEUE)
   AUTHLIST(BROWSE,CHG,CLR,DLT,DSP,GET,INQ,PUT,PASSALL,PASSID,SET,SETALL,SETID)

This is just like the first section, except I had defined it for principal (userid) testuser – not a group.

Using DIS AUTHREC gave

dis authrec profile(CP0000) objtype(queue) group('testuser')
AMQ8864I: Display authority record details.
PROFILE(CP0000) ENTITY(testuser)
ENTTYPE(GROUP) OBJTYPE(QUEUE)
AUTHLIST(BROWSE,GET,INQ,PUT,PASSALL,PASSID,SET,SETALL,SETID)

dis authrec profile(CP0000) objtype(queue) principal('testuser')
4 : dis authrec profile(CP0000) objtype(queue) principal('testuser')
AMQ8459I: Not found.

However if I display information about the userid, it displays

uid=1002(testuser) gid=1004(testuser) groups=1004(testuser),1005(test)

so there is a group for the userid as well as the userid itself.

All in all – I found this a little confusing.

Other profiles.

AMQ8864I: Display authority record details.
   PROFILE(**)                             ENTITY(test)
   ENTTYPE(GROUP)                          OBJTYPE(TOPIC)
   AUTHLIST(DSP)

There is a generic profile ** for object type topic. If there was a topic CP0000 then userid/group test would have DSP access.

Displaying what you want

You can limit the object type displayed

dis authrec profile(CP0000) objtype(queue)

this just displayed the queue records for profile CP0000 (and so did not display the topic record above), so you can be selective.

You can use

dis authrec profile(CP0000) objtype(queue) group(‘testuser’)

or principal(‘userid’) to display records for just a group or userid.

However

dis authrec profile(‘CP*’) objtype(Queue)

gives

AMQ8459I: Not found.

Because there is no profile with name CP*. It does not display all profiles beginning with CP.

Using setmqaut

I wanted to test out context security, and did not want my application to be able to set certain fields in the MQMD.

If the userid had permissions, put and setall, my application was able to set the application name.

I turned off the permission with

setmqaut -m QMA -n CP0000 -p testuser -t queue -setall

and got rc=2035 MQRC_NOT_AUTHORIZED as expected.

Note: The userid also needs the “global level” switch

setmqaut -m QMA –t qmgr -p testuser +setall

enabled at the queue manager level. The application needs both +setall permissions to be able to set these context fields in the MQMD at put time.

This is not the end of the story…

With my normal administrator userid colinpaice, I used

setmqaut -m QMA -n CP0000 -t queue -p colinpaice -setall

to remove the setall permission; and this had no effect! I was still able to set the certain fields in the MQMD.

Hidden away in the documentation is a line

If a principal is a member of more than one user group, the principal effectively has the combined authorities of all those user groups

After I issued the setmqauth command, the dspmqauth command

dspmqaut -m QMA -n CP0000 -t queue -p colinpaice

gave

get
put
setall

which shows the userid still has setall access.

From the dis authrec command, it gave

2 : dis authrec profile(CP0000) objtype(QUEUE) 
AMQ8864I: Display authority record details.
PROFILE(CP0000) ENTITY(mqm)
ENTTYPE(GROUP) OBJTYPE(QUEUE)
AUTHLIST(BROWSE,CHG,CLR,DLT,DSP,GET,INQ,PUT,PASSALL,PASSID,SET,SETALL,SETID)

so the group mqm has SETALL access to the queue.

It gets more confusing. I used the command

setmqaut -m QMA -n CP0000 -t queue -p colinpaice -setall

to turn off setall permissions

dspmquth with -p colinpaice showed setall

dspmquth with -g colinpaice did not have setall!

This has me stumped for a few hours!

Being in the mqm group trumps the setmqaut definitions.

If a userid is in the mqm group, then it looks like there are no other checks. An implications of this is if your development team are in the mqm group, and they checking “error paths”, the MQ call will work, when it would fail for non group mqm users.

I used

sudo gpasswd –d colinpaice mqm

to remove my userid from the group. I had to use the runmqsc command refresh security command to get the queue manager to pick up the change.

Once I had done this then the setmqaut commands with +setall and -setall worked as expected. I used

sudo gpasswd –add colinpaice mqm

and the runmqsc refresh security command, for the setmqaut commands to be ignored.

The command

dspmqaut -m QMA -n CP0000 -t queue -p colinpaice

was accurate, in that when the userid was in the group, the command shows what access the userid has.

When the userid was not in the group, I remove access

setmqaut -m QMA -n CP0000 -t queue -p colinpaice -remove

the display command gave

Entity colinpaice has the following authorizations for object CP0000:
crt

When the userid was in group mqm the dspmqaut command gave

dspmqaut -m QMA -n CP0000 -t queue -p colinpaice
Entity colinpaice has the following authorizations for object CP0000:
get
browse
put
inq
set
crt
dlt
chg
dsp
passid
passall
setid
setall
clr