| Author |
Message
|
| mqdogsbody |
 Posted: Tue Apr 23, 2013 9:35 am Post subject: MQ Authorization and Unix Groups |
 |
|
Acolyte
Joined: 01 Jun 2010
Posts: 71
|
As I explained in another message, I am a little confused about how MQ authorization works w.r.t. UNIX groups.
All the documentation for UNIX systems emphasizes the primary group. That makes sense when granting authorization.
But what about when authorization is checked? Is just the principal's primary group considered or all its group memberships?
I kind of assumed that (following the UNIX model) all the principal's groups are checked and various things I have read (including the posts in the thread I have referenced above) suggest that this is correct, even though it is never spelled out in black and white.
But an experiment suggest that it is the primary group that matters and other group memberships are not taken into account. Consider this queue and the access that group infosys has:
| Code: |
dspmqaut -m PARDOEJ2 -t queue -n AUTH.TEST.1 -g infosys
Entity infosys has the following authorizations for object AUTH.TEST.1:
get
browse
put
inq
set
crt
dlt
chg
dsp
passid
passall
setid
setall
clr
|
As myself I run this and try to connect as two different users, one of which has infosys as its primary group
| Code: |
| uid=7271(stdevad) gid=128(infosys) |
and one of which doesn't:
| Code: |
| uid=1210898(axlsvqa1) gid=1200423(axlsvqa1) |
This second use is a member of infosys, as the output of the "groups" command shows
| Code: |
| axlsvqa1 global1 infosys |
So, as I understand, it both users should be able to browse my queue. Yet one can and the other can't:
| Code: |
Actual user running script is pardoej (uid=28936(pardoej) gid=128(infosys); groups: infosys glccusers lobamedgrp motech tecindev finsupp docadmin devadm lobamepgrp devinfra)
========================================================================
Accessing AUTH.TEST.1 as stdevad (uid=7271(stdevad) gid=128(infosys); groups: infosys global1 istest glccusers)
VERSION: MQTOOLS1.12.F; 08-Nov-2011, 15:19
CONNECT: Using channel SYSTEM.DEF.SVRCONN
CONNECT: MQ environment user ID set to stdevad
CONNECT: PARDOEJ2@lonux20507:1432
OPEN: AUTH.TEST.1 with {BROWSE}
BROWSE: Test message on queue AUTH.TEST.1 [pardoej@lonux10057 to pardoej2/AUTH.TEST.1 on Tue Apr 23 18:15:47 BST 2013]
========================================================================
Accessing AUTH.TEST.1 as axlsvqa1 (uid=1210898(axlsvqa1) gid=1200423(axlsvqa1); groups: axlsvqa1 global1 infosys)
VERSION: MQTOOLS1.12.F; 08-Nov-2011, 15:19
CONNECT: Using channel SYSTEM.DEF.SVRCONN
CONNECT: MQ environment user ID set to axlsvqa1
CONNECT: PARDOEJ2@lonux20507:1432
Exception in thread "main" mqtools.MQUtilException: MQ operation 'connect' failed; completion code: MQCC_FAILED (2); reason: MQRC_NOT_AUTHORIZED (2035)
at mqtools.MQUtil.connect(MQUtil.java:932)
|
So, it looks as if only the primary group is taken into account and other group memberships are irrelevant.
Is this right? Can someone please point me to clear and explicit documentation of this fact.
Or have I done something wrong?
_________________
-- mqDB -- |
|
| Back to top |
|
 |
| mqdogsbody |
| Posted: Wed Apr 24, 2013 8:07 am Post subject: Re: MQ Authorization and Unix Groups |
|
|
Acolyte
Joined: 01 Jun 2010
Posts: 71
|
| mqdogsbody wrote: |
| Can someone please point me to clear and explicit documentation of this fact. |
Reading the page I cited a bit more carefully
| Principals and groups wrote: |
| A principal can belong to more than one group (its group set) and has the aggregate of all the authorities granted to each group in its group set. |
To me that suggests the "all groups" interpretation is correct. Yet my experiment suggests that the "primary group only" interpretation is correct.
... as does this quick test:
| Code: |
| for u in stdevad axlsvqa1; do print "User: $u; groups $(groups $u)"; dspmqaut -m PARDOEJ2 -t queue -n AUTH.TEST.1 -p $u; print "==="; done |
Output:
| Code: |
User: stdevad; groups infosys global1 istest glccusers
Entity stdevad has the following authorizations for object AUTH.TEST.1:
get
browse
put
inq
set
crt
dlt
chg
dsp
passid
passall
setid
setall
clr
===
User: axlsvqa1; groups axlsvqa1 global1 infosys
Entity axlsvqa1 has the following authorizations for object AUTH.TEST.1:
=== |
What am I doing wrong?
dspmqver says
| Code: |
Name: WebSphere MQ
Version: 6.0.2.5
CMVC level: p600-205-080922
BuildType: IKAP - (Production) |
uname -a says
| Code: |
| SunOS lonux20507 5.10 Generic_142900-03 sun4u sparc SUNW,SPARC-Enterprise |
|
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Apr 24, 2013 7:47 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY
|
Seems to be you are getting confused about setting authorizations and checking them.
Don't necessarily use dspmqaut you may not be getting what you expect.
Use instead dmpmqaut for the specific object you want to check. You will then see all the groups that have authorizations.
Remember that setmqaut will only set permissions to the primary group of the user. This is why I would really use the setting of permissions at the group level and never at the principal level. Have then the principal move in and out of groups as needed.
Remember WMQ caches the OS level info after start. So when you switch a principal from one group to the other, you may want to issue a refresh security to the qmgr afterwards... to make it aware of the switch...
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| mqdogsbody |
| Posted: Thu Apr 25, 2013 1:03 am Post subject: |
|
|
Acolyte
Joined: 01 Jun 2010
Posts: 71
|
| fjb_saper wrote: |
| Seems to be you are getting confused about setting authorizations and checking them. |
Well, didn't I say that? I understand what happens when setting authorizations but not when checking them.
| fjb_saper wrote: |
| Remember that setmqaut will only set permissions to the primary group of the user. |
Ys, I understand that. (Did I not make it clear? I meant to.) It's what happens when authorizations are checked that I am unsure about: primary group only or all groups?
To rephrase, my questions are:
- When authorizations are checked is it only the principal's primary group that is taken into account or is it all his/her group memberships?
- Where in the documentation is this explcitly stated?
| fjb_saper wrote: |
| Don't necessarily use dspmqaut you may not be getting what you expect. |
As I understand it, dmpmqaut shows the raw data which the OAM uses to calculate access rights, whereas dspmqaut shows the results of that calculation. It was the results I wanted here.
_________________
-- mqDB -- |
|
| Back to top |
|
|
| mvic |
| Posted: Thu Apr 25, 2013 1:27 am Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| mqdogsbody wrote: |
To rephrase, my questions are:
- When authorizations are checked is it only the principal's primary group that is taken into account or is it all his/her group memberships?
- Where in the documentation is this explcitly stated?
|
Does this help?
Page title is: "dspmqaut"
Text is: "If a user ID is a member of more than one group, this command displays the combined authorizations of all the groups."
URL is: http://pic.dhe.ibm.com/infocenter/wmqv7/v7r5/topic/com.ibm.mq.doc/fa15700_.htm |
|
| Back to top |
|
|
| mqdogsbody |
| Posted: Thu Apr 25, 2013 2:00 am Post subject: |
|
|
Acolyte
Joined: 01 Jun 2010
Posts: 71
|
| mvic wrote: |
Does this help?
Page title is: "dspmqaut"
Text is: "If a user ID is a member of more than one group, this command displays the combined authorizations of all the groups." |
Thanks! That is a clear and explicit statement, and it fits in with what I thought I understood. But this is not the end of the story because my experiment suggest that this statement is not true!!!
In my experiment axlsvqa1 is a member of group infosys but has no access. (See the root message.) If the statement you cite were true it should have access ... I believe:
| Code: |
> dmpmqaut -m PARDOEJ2 -t queue -n AUTH.TEST.1
profile: AUTH.TEST.1
object type: queue
entity: infosys
entity type: group
authority: allmqi dlt chg dsp clr
- - - - - - - -
profile: AUTH.TEST.1
object type: queue
entity: mqm
entity type: group
authority: allmqi dlt chg dsp clr
> groups axlsvqa1
axlsvqa1 global1 infosys |
Wouldn't you agree? What have I misunderstood? What am I doing wrong?
_________________
-- mqDB -- |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Apr 25, 2013 3:56 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| did you refresh security or restart the qm after changing the membership of the infosys group? |
|
| Back to top |
|
|
| mqdogsbody |
| Posted: Thu Apr 25, 2013 4:36 am Post subject: |
|
|
Acolyte
Joined: 01 Jun 2010
Posts: 71
|
| mqjeff wrote: |
| Did you refresh security or restart the qm after changing the membership of the infosys group? |
Not explicitly, but the user account has been in that group for ages (since it was set up) and my QM is stopped automatically every Friday and I restart it as required. I am fairly confident the QM security info is up-to-date.
Anyway, I did a REFRESH SECURITY just in case and reran my test script. No change!
_________________
-- mqDB -- |
|
| Back to top |
|
|
| mvic |
| Posted: Thu Apr 25, 2013 6:51 am Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
Do you have LDAP, Active Directory, etc. etc. in place as your user/group system? Or is it default passwd/group implementation?
MQ clearly thinks axlsvqa1 is not a member of any group that has any authorization. |
|
| Back to top |
|
|
| mqdogsbody |
| Posted: Thu Apr 25, 2013 8:28 am Post subject: |
|
|
Acolyte
Joined: 01 Jun 2010
Posts: 71
|
| mvic wrote: |
| Do you have LDAP, Active Directory, etc. etc. in place as your user/group system? |
It is LDAP-based (as I understand it).
Either way, that raises some interesting questions. What difference might it make and why? |
|
| Back to top |
|
|
| mvic |
| Posted: Thu Apr 25, 2013 9:14 am Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| mqdogsbody wrote: |
| Either way, that raises some interesting questions. What difference might it make and why? |
Try using basic passwd/group instead and see if it makes a difference.
(Restart your qmgr or use "REFRESH SECURITY" to purge cached info about group membership if making a change of that sort.)
MQ does not know what is being used under the covers of the OS. If it makes a difference what you use (I don't know one way or the other, in your case) then the question "why" is one for your OS support people. |
|
| Back to top |
|
|
| mqdogsbody |
| Posted: Fri Apr 26, 2013 12:44 am Post subject: |
|
|
Acolyte
Joined: 01 Jun 2010
Posts: 71
|
| mvic wrote: |
| Try using basic passwd/group instead and see if it makes a difference. |
I am not sure I can do that .. unless it's a setting within MQ.
| mvic wrote: |
| MQ does not know what is being used under the covers of the OS. |
I should hope not (... which also suggests there's no "setting within MQ").
| mvic wrote: |
| If it makes a difference what you use |
Why should it make a difference? That's the kind of thing I was hoping you would tell me!! I got all excited ...
I remember running into a problem with large groups before, but I think that was a Windows-specific problem. Still this is a large group and if I run ypcat group | grep infosys I see some kind of chaining: infosys contains infosys--001 and so on.
Still, I would hope that MQ would use standard OS faculties and those facilities would "get it right". And if the facilities didn't "get it right" I imagine someone might have noticed by now. (Nonetheless I will experiment.)
| mvic wrote: |
| the question "why" is one for your OS support people |
Well, if the standard OS faculties "get it right" they'll just say"it works". It's an MQ question!
_________________
-- mqDB -- |
|
| Back to top |
|
|
| mvic |
| Posted: Fri Apr 26, 2013 12:54 pm Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| mqdogsbody wrote: |
| mvic wrote: |
| Try using basic passwd/group instead and see if it makes a difference. |
I am not sure I can do that .. unless it's a setting within MQ. |
No, it's a change to your OS.
| Quote: |
| mvic wrote: |
| If it makes a difference what you use |
Why should it make a difference? That's the kind of thing I was hoping you would tell me!! I got all excited ... |
You are welcome to try the idea I suggested, or not. If you don't try it, how will you know if it helps or not. Myself, I cannot possibly know if it will help. But I have seen problems in this area before, and so I made the suggestion.
| Quote: |
| Still, I would hope that MQ would use standard OS faculties and those facilities would "get it right". And if the facilities didn't "get it right" I imagine someone might have noticed by now. (Nonetheless I will experiment.) |
Good 
| Quote: |
| mvic wrote: |
| the question "why" is one for your OS support people |
Well, if the standard OS faculties "get it right" they'll just say"it works". It's an MQ question! |
If it helps to use the traditional passwd/groups method, that would suggest something fairly strongly in the opposite direction. |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Apr 26, 2013 3:10 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqdogsbody wrote: |
| mvic wrote: |
| the question "why" is one for your OS support people |
Well, if the standard OS faculties "get it right" they'll just say"it works". It's an MQ question! |
Beg to differ. WMQ relies on the underlying OS for this feature. If the underlying OS has in fact handed this off to LDAP or similar, and LDAP does not properly provide the information WMQ needs it's not an MQ question.
For the record, I tend to agree with @mvic and suspect that it's related to your LDAP configuration. I've seen this sort of thing before where WMQ (and Oracle, and DB2) all claim people are not members of groups they patently are members of, or that groups do not have rights they patently should have, and in each instance of my experience the problem has been resolved by either a change to the LDAP configuration, a change to the way LDAP is mapped to the OS security or just the LDAP server being restarted. In all instances, the sys admins are your first port of call. If only to provide a trace of what's going on in the OS when WMQ calls out for security.
Which OS is this, and what are you using for LDAP services?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqdogsbody |
| Posted: Sat Apr 27, 2013 2:37 am Post subject: |
|
|
Acolyte
Joined: 01 Jun 2010
Posts: 71
|
| mvic wrote: |
| No, it's a change to your OS [...] If you don't try it, how will you know if it helps or not. |
That's way beyond the kind of thing I am allowed to do. And I doubt that our Unix admin people (or our auditors) would take kindly to the suggestion that we change it, even as an experiment.
| mvic wrote: |
| But I have seen problems in this area before |
But that in itself is interesting! But I would also imagine that this would be a "well-known problem". We can't be the only people who have tried running MQ 6 on Solaris using LDAP.
And it's progress too, in the sense that I now know what should happen and that the behaviour I see is not what should happen.
| mvic wrote: |
| mqdogsbody wrote: |
| mvic wrote: |
| the question "why" is one for your OS support people |
Well, if the standard OS faculties "get it right" they'll just say"it works". It's an MQ question! |
If it helps to use the traditional passwd/groups method, that would suggest something fairly strongly in the opposite direction. |
Well, I don't want to quibble over semantics but my view is that if the Unix-level access stuff displays the right behaviour (and it does - I did experiment) then the question "Is it an O/S problem" gets the answer "No - the O/S gets it right". If MQ doesn't get it right we have to look at MQ.
But if it is a "well-known problem" I am more interested in knowing that, and knowing what will happen with MQ7. We might get around to migrating at some point...
_________________
-- mqDB -- |
|
| Back to top |
|
|
|
|
