|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
 |
|
unix group strategy for setmqaut |
« View previous topic :: View next topic » |
Author |
Message
|
Bill Wilson |
Posted: Wed Apr 21, 2004 6:22 am Post subject: unix group strategy for setmqaut |
|
|
Newbie
Joined: 15 Feb 2003 Posts: 8
|
Hello, Anyone share their strategy for setting up unix groups and assigning
authorites using setmqaut?
I have mostly j2ee app servers accessing mq locally (not client mode).
The apps are all running under the same unix login.
I also have mq on another unix box accessed by mulitiple applications
( not j2ee).
thanks |
|
Back to top |
|
 |
Michael Dag |
Posted: Wed Apr 21, 2004 1:46 pm Post subject: |
|
|
 Jedi Knight
Joined: 13 Jun 2002 Posts: 2607 Location: The Netherlands (Amsterdam)
|
I don't exactly understand what you are looking for.
On unix authority is stored on the group level even when assigned using -p,
so with that in mind if you have different users needing different levels of authority you need different groups aswell.
hope this helps. _________________ Michael
MQSystems Facebook page |
|
Back to top |
|
 |
Bill Wilson |
Posted: Thu Apr 22, 2004 10:13 am Post subject: |
|
|
Newbie
Joined: 15 Feb 2003 Posts: 8
|
Hi, thanks for the response.
Do you create MQ specific groups, say mqapp1, mqapp1, ...
and assign users? or set authorites to exsisting groups.
I am not a unix admin.
thanks in advance.
bill |
|
Back to top |
|
 |
SAFraser |
Posted: Fri Apr 23, 2004 9:35 am Post subject: |
|
|
 Shaman
Joined: 22 Oct 2003 Posts: 742 Location: Austin, Texas, USA
|
We have asked our unix admins to create a specific group for us (mquser) and then add the needed login IDs to that group. Then we setmqaut for that group on the appropriate mq objects.
The granularity of your group structure depends on what you want to accomplish, I guess. If all your developers/applications play nice together, then you could do it with a single group. The drawback in unix is that MQ reads only the group membership so setting authority at the login ID (principal) level is useless; worse than useless, it actually changes the settings for the primary group of the principal so you can be changing a group's authority by setting a principal's authority. If you need to set security at a user level, you will have to have a group for each user.
Here is something that caught us, which I'll mention in case you don't know about it already. My unix login ID is a member of the "mqm" group; so, I had been creating queue managers and queues under my own ID. However, the PRIMARY group for my unix login ID was a generic group called "staff". (My mqm group membership was a secondary group.) When an MQ object is created in Unix, the group "mqm" and the PRIMARY group of the creator are both given ALL rights to the object. So for a long time we were creating objects that anyone in the generic "staff" group could access. Not our finest hour as mq admins. (Yes, now we always "su" to create objects.)
Hope this is useful. |
|
Back to top |
|
 |
Bill Wilson |
Posted: Fri Apr 23, 2004 10:13 am Post subject: |
|
|
Newbie
Joined: 15 Feb 2003 Posts: 8
|
Thanks. This answers my question and thanks for the gotcha.
bill |
|
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
|
|
|
|