I was asked to explain how the midrange security commands work. At first glance it looked pretty easy, but then I tried to use them, and got very confused when it did not work as I expected.
Some of the complexity comes from userids which are also groups, definitions which look like generics but are not generic, some of the definitions seem backwards, and some more documentation is needed! Read on to see how I was baffled and felt very confused.
I was talking to Morag on this, and she said that MQGEM do education on authorization – see here.
I was running on Ubuntu (18.04)
Queue manager running userid or group based authorization.
A queue manger can be set up to use user-based or group-based authorization. See here and here. The default is group based.
A linux userid has a private group with the same name as the userid
I set up a userid testuser which had effectively no authority to do anything. This has a (private) group with the same name as the userid. See here.
The command id testuser gives
uid=1002(testuser) gid=1004(testuser) groups=1004(testuser)
sudo groupadd test
sudo adduser testuser test
to add testuser to the group called test, and will use group test in the rest of the discussions.
There are two ways of displaying and setting MQ authorisation information
There are two ways of using the MQ security commands
- Runmqsc and display/delete/set AUTHREC. You can use runmqsc as a client from a remote machine. This can be used for an MQ appliance.
- setmqauth and dspmqauth shell commands. You need to have access to the shell environment to be able to issue these commands. This cannot be used for an MQ appliance.
The documentation has similar content but the runmqsc set authrec command is slightly better.
For example see here.
- runmqsc set authrec explains DSP : Display the attributes of the specified object using the appropriate command set . But it is not clear what a command set is. I think it means PCF or MQSC.
- setmqauth shows DSP – but does not explain what DSP provides
The syntax of the commands is similar, but different, and this caught me out for a while. For example I used
setmqauth -m QMA -t qmgr -p testuser +inq -dsp
but with the runmqsc I had to specify principal(‘testuser’) in quotes – because as with all runmqsc fields they get converted to upper case when the string is not quoted!
Creating and using profiles
I created profiles
set AUTHREC PROFILE(COLIN_1) OBJTYPE(QUEUE) group('test') AUTHADD(GET)
set AUTHREC PROFILE(COLIN_2) OBJTYPE(QUEUE) group('test') AUTHADD(SET)
set AUTHREC PROFILE(COLIN_3*) OBJTYPE(QUEUE) group('test') AUTHADD(INQ)
set AUTHREC PROFILE(COLIN_*) OBJTYPE(QUEUE) group('test') AUTHADD(GET,PUT)
When security checks are done, if there are choice of records for a queue the definition, is the most specific one. See here. I could not find anything in MQ which told me which actual profile was used – even though MQ knows this information!
If ‘testuser’ in group test, wants to access some queues, the userid can open
COLIN_1 for get
COLIN_2 for set
COLIN_3 for inquire
COLIN_33 for inquire. The COLIN_3* is more specific than COLIN_*
QUEUE_11 for put + get. This is from the COLIN_* definition.
Displaying a profile
If you issue DIS QUEUE(COLIN*), the * acts as a generic character and says display any queues beginning with COLIN.
The DIS AUTHREC is different. DIS AUTHREC PROFILE(COLIN*) does not say show all profiles beginning with COLIN, it says show me the actual profile COLIN* . Just the same as if it was COLIN@.
Below are some display commands and their responses
DIS AUTHREC PROFILE(COLIN*) returned no object, as explained above.
DIS AUTHREC PROFILE(COLIN_*) this is saying give me the specific profile COLIN_* and it returned
PROFILE(COLIN_*) ENTITY(test) ENTTYPE(GROUP) OBJTYPE(QUEUE) AUTHLIST(GET)
DIS AUTHREC PROFILE(COLIN_1) returned two entries (as both of them could potentially apply)
PROFILE(COLIN_1) … AUTHLIST(GET)
PROFILE(COLIN_*) … AUTHLIST(GET,PUT)
DIS AUTHREC PROFILE(COLIN_*) GROUP(test)returned
AMQ8459I: Not found. This is because the test became upper case TEST
DIS AUTHREC PROFILE(COLIN_*) GROUP(‘test’) returned
PROFILE(COLIN_*) … AUTHLIST(GET)
DIS AUTHREC PROFILE(COLIN_*) group(‘mqm’) returned
AMQ8459I: Not found.
If you issue a display command for a generic looking profile – it will display profiles with the specific name including the ‘*’.
If you display a specific looking name, it will act like a generic, and display all the records which apply to the specific name.
So you can see why I was confused – but it gets more complex.
There is a parameter MATCH with default PROFILE which says return the profiles and the the value of the principal eg GROUP(TEST), this is what happened above.
There is also MATCH(MEMBERSHIP). This looks into the definitions and gets the list of the userid’s groups and displays the authrecs for the specified userid.
dis authrec profile(COLIN_2) objtype(queue) principal(‘testuser’) match(membership)returned
PROFILE(COLIN_2) ENTITY(test) ENTTYPE(GROUP) … AUTHLIST(SET)
This is because userid testuser is in group test.
You can also specify MATCH(EXACT). This returns the specified profile, and specified principle.
DIS AUTHREC PROFILE(COLIN_1) match(PROFILE)returned
DIS AUTHREC PROFILE(COLIN_1) match(EXACT)returned
How do I find the list of profiles if I cannot use a generic search argument?
To list all queue auth records applicable for group test use
DIS AUTHREC objtype(QUEUE) group(‘test’)
To list all available auth records applicable for group test use
DIS AUTHREC group(‘test’)
To list all auth records, for all objects for all users and groups use
DIS AUTHREC which you may want to capture in a file using
echo “DIS AUTHREC “ |runmqsc QMA > authrec.txt
One thought on “These display authority commands are difficult to use!”