| Author |
Message
|
| bkRaju |
 Posted: Fri Jun 03, 2011 5:18 am Post subject: setmqaut |
 |
|
Centurion
Joined: 19 Aug 2008
Posts: 106
|
Hi All,
Question is why I am still seeing put permitted though I did "put" not permitted, what is the wrong in below sequential actions?
it is in mq vesion7.
uid=(mqm) gid=(mqm) groups=(mqbrkrs)
SERVER1:mqm# setmqaut -m TESTQM -n TESTQL -t queue -p mqm -put
The setmqaut command completed successfully.
SERVER1:mqm # setmqaut -m TESTQM -n TESTQL -t queue -g mqm -put
The setmqaut command completed successfully.
SERVER1:mqm # dspmqaut -m TESTQM -n TEST -t q -g mqm
Entity mqm has the following authorizations for object TEST:
get
browse
put
inq
set
crt
dlt
chg
dsp
passid
passall
setid
setall
clr
SERVER1:mqm # dspmqaut -m TESTQM -n TEST -t q -p mqm
Entity mqm has the following authorizations for object TEST:
get
browse
put
inq
set
crt
dlt
chg
dsp
passid
passall
setid
setall
clr
SERVER1:mqm # |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Fri Jun 03, 2011 5:39 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
First, you can't ever reduce the permissions of the mqm user.
Second, on unix, you ALWAYS issue setmqaut against the GROUP and NOT the Principle.
Strike three, both of these things should be obvious from the documentation. |
|
| Back to top |
|
|
| exerk |
| Posted: Fri Jun 03, 2011 5:41 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
Do not give principles authorisations on UNIX, it leads to unexpected results, of which there is much discussion within this site. As for trying to alter authorisations for mqm, whether group or principle, do you really think you would be able to alter any authorisations for the group responsible for full administration of WMQ?
Moving this to the Security forum, where it logically belongs...
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Jun 03, 2011 7:07 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
This is why you never, ever, add end-users (non-administrators) to mqm group.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| bkRaju |
| Posted: Sun Jun 05, 2011 9:32 pm Post subject: |
|
|
Centurion
Joined: 19 Aug 2008
Posts: 106
|
Thanks all for the response. Good learing.
I have requirement that, developers have the access to mqm but not for mb7 and I need to restrict them from usinig SYSTEM.BROKER.AUTH so that they should not perfom any broker related operations.
Let me know the soultion for above point.
Thanks, |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sun Jun 05, 2011 9:48 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| bkRaju wrote: |
Thanks all for the response. Good learning.
I have requirement that, developers have the access to mqm but not for mb7 and I need to restrict them from using SYSTEM.BROKER.AUTH so that they should not perform any broker related operations.
Let me know the solution for above point.
Thanks, |
 broker infocenter chapter on security 
It's all there 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| zpat |
| Posted: Sun Jun 05, 2011 11:26 pm Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
| On Unix, when someone creates a queue, it adds their primary group to the ACL. This can be very annoying if the primary group is something like "users". |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Jun 06, 2011 4:00 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| bkRaju wrote: |
| Let me know the soultion for above point. |
As MB7 uses WMQ security, and devleopers have admin (mqm) authority, there's no solution that will prevent a developer who can read the InfoCenter circumventing the security.
The solution is to not give non-admin staff (like developers) mqm access. Why do they need it? And don't say "because they're developing". I'd heard that one - my rebuttle is that they're developing code not WMQ.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bkRaju |
| Posted: Mon Jun 13, 2011 1:15 am Post subject: |
|
|
Centurion
Joined: 19 Aug 2008
Posts: 106
|
| Yes,In our Project, developer will have access to mqm. so is anyother way to restrict developer from mb7 operations? |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Jun 13, 2011 4:08 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| bkRaju wrote: |
| Yes,In our Project, developer will have access to mqm. |
I repeat, why?
| bkRaju wrote: |
| so is anyother way to restrict developer from mb7 operations? |
No.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bkRaju |
| Posted: Mon Aug 01, 2011 7:05 am Post subject: |
|
|
Centurion
Joined: 19 Aug 2008
Posts: 106
|
I tried to give all permissions to all queues as below for a MQ7 qmgr.
setmqaut -m QMNAME -n '**' -t q -p username +all
dspmqaut -m QMNAME -n TEST -t q -p username
Entity username has the following authorizations for object TEST:
It is blank, that means no authority for TEST queeu. So is somethng wrong in first command?
My intention is to give all authorities for all qs in qmgr QMNAME.
Thanks for your reply. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Aug 01, 2011 7:37 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| bkRaju wrote: |
| It is blank, that means no authority for TEST queeu. So is somethng wrong in first command? |
If it's not issued on a Windows box, using that -p flag may not give you the result you expect.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
