| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Browse without get (with q) |
« View previous topic :: View next topic » |
| Author |
Message
|
| TJo |
 Posted: Fri Apr 22, 2005 10:13 am Post subject: Browse without get (with q) |
 |
|
Novice
Joined: 26 Jul 2004
Posts: 18
Location: Gothenburg Sweden
|
Hi!
I am trying to raise the security on some qms we run for a customer. The customer is demanding browse access om some application queues but explicitly do not want put, get or admin rights.
Sure, this is to be able to say "We did'nt do anything" if some message vanish into thin air. Actually I do agree with them. It will be good to know that any vanishing is not due to customer fumbling on a button in MQ*explorer or some such.
I have been able to fix all of it but for one little detail, namely "get".
If i disable get on the queue, for the group, then I cannot browse the queue. But is it not possible to define the security on a queue as +allmqi -get -put and still be able to browse it? After all browse is still set.
Using the q (ma01) program I get a 2035 while trying to browse the queue without get allowed. If get is always needed to be able to browse, then what is the meaning of the browse permission?
-*- time passes -*-
* please do not use *!!!! I just discovered that with MO71 I get the behaviour I want, and also with MQVisual Browse that I downloaded a few minutes ago.
But not with the q program which I used for testing.
What is the difference between running locally, as with q, and remotely via SVRCONN channels, as with MO71. Have I overlocked something obvious or...? This makes me a bit doubtful about what I have accomplished.
Now I am to tired to think.
Its past 20:00 on a Friday and I am still at work 
Thanks in advance for any comments. Have a nice weekend. Its springtime here in Sweden 
TJo
_________________
"Always code as if the guy who ends up maintaining your code will be
a violent psychopath who knows where you live." --Martin Golding |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Fri Apr 22, 2005 10:23 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Browse can cause messages to expire.
So they can't claim that browse is a safe operation.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Apr 22, 2005 11:15 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
and if you do get the browse to work, who is to say they wont do a browse with a lock under cursor, preventing the real app from getting the message?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| TJo |
| Posted: Mon Apr 25, 2005 3:40 am Post subject: |
|
|
Novice
Joined: 26 Jul 2004
Posts: 18
Location: Gothenburg Sweden
|
jefflowrey wrote:
| Quote: |
Browse can cause messages to expire.
So they can't claim that browse is a safe operation.
|
True, but that is something I mostly see as a bonus. If a message is older than its expire date, it should be thrown out and, e.g. not trigger any alarms.
PeterPotkay wrote:
| Quote: |
and if you do get the browse to work, who is to say they wont do a browse with a lock under cursor, preventing the real app from getting the message?
|
Good point Peter. Did not thought about that. However they will use tools like MO71, MQJexplorer or MQVisual Browse, and hopefully will not meddle with anything like that. It is in their own interest that everything is working well after all. But I will sure pop this up the next time I talk with the customer. Still think the risk for a get by mistake is much greater though.
But my main puzzlement (is that a word ?-) is still unsolved. What is the difference, security wise, between using q locally or MO71, et al via a SVRCONN channel. There are no security exits anywhere, yet.
_________________
"Always code as if the guy who ends up maintaining your code will be
a violent psychopath who knows where you live." --Martin Golding |
|
| Back to top |
|
|
| oz1ccg |
| Posted: Mon Apr 25, 2005 4:08 am Post subject: |
|
|
Yatiri
Joined: 10 Feb 2002
Posts: 628
Location: Denmark
|
Anyway, if the applications are correctly designed, then they should not have problems with expired messages. This is a real world situation, so important data/messages are allways sent as Persistent and with no-expire. This leaves me with a question, who can we trust ?
And about having a MQBROWSE deleteing expired messages, don't care, this is just normal procedure, you can't retrive them anyway.
And you can "only" lock a single message or a single group, using one connection, so this limits the damage...
Who is owning the data ? This is the customer, and it's the customers people that have access.... This means just log the connects, and keep a journal... Maybee even having the messages logged in some way using a exit....
Just my $0.02 
_________________
Regards, Jørgen
Home of BlockIP2, the last free MQ Security exit ver. 3.00
Cert. on WMQ, WBIMB, SWIFT. |
|
| Back to top |
|
|
| vmcgloin |
| Posted: Mon Apr 25, 2005 4:14 am Post subject: |
|
|
Knight
Joined: 04 Apr 2002
Posts: 560
Location: Scotland
|
TJo,
I don't know the answer but is it related to the mca userid on your SVRCONN channels? Is it set? I would still want to test, e.g. with amqsbcg, locally.
And, I'm sure you were running refresh security for the qmgr right?
Cheers,
Vicky |
|
| Back to top |
|
|
| oz1ccg |
| Posted: Mon Apr 25, 2005 4:43 am Post subject: |
|
|
Yatiri
Joined: 10 Feb 2002
Posts: 628
Location: Denmark
|
As I see the major concern: MQGMO_LOCK can lockup a message and hide it from the lagacy application, and just wait to let expire, and it's gone. This is possible just having browse auth. 
This is the behavour of WMQ. I'm shure that the service bureau are controlling who is allowed to connect to the SVRCONN, and logging the connection attempts.... with an exit of some type or by using SSL.
This could be helped using my BlockIP2 or the one from Roger.
Just my $0.02
_________________
Regards, Jørgen
Home of BlockIP2, the last free MQ Security exit ver. 3.00
Cert. on WMQ, WBIMB, SWIFT. |
|
| Back to top |
|
|
| TJo |
| Posted: Mon Apr 25, 2005 5:32 am Post subject: |
|
|
Novice
Joined: 26 Jul 2004
Posts: 18
Location: Gothenburg Sweden
|
| vmcgloin wrote: |
TJo,
I don't know the answer but is it related to the mca userid on your SVRCONN channels? Is it set? I would still want to test, e.g. with amqsbcg, locally.
And, I'm sure you were running refresh security for the qmgr right?
Cheers,
Vicky |
I have a test queue named AB1 on qm B, a user named mqro and a SVRCONN channel named CUSTOMER.READONLY with MCAUSER set to mqro. This server is running under Linux 2.4.21 and the client under w2k.
The security set on the AB1 queue are: browse and inq.
MO71 is connecting through the channel, and can browse the queue AB1 without any problems. Same thing with MQVisual Browse. But when running q locally as the user mqro I get the following:
| Quote: |
>Q -m B -iAB1
MQSeries Q Program by Paul Clarke [ V4.3 Build:Jun 9 2004 ]
Connecting ...connected to 'B '.
MQOPEN on object 'AB1' returned 2035 Not authorized..
|
As soon as get was added to the permissions on AB1 I could browse the queue.
I also tested with permissions on the queue set to: browse, inq, set, passid, passall, setid and setall with equal results.
Refreshed everytime I changed any security settings.
_________________
"Always code as if the guy who ends up maintaining your code will be
a violent psychopath who knows where you live." --Martin Golding |
|
| Back to top |
|
|
| TJo |
| Posted: Mon Apr 25, 2005 5:53 am Post subject: |
|
|
Novice
Joined: 26 Jul 2004
Posts: 18
Location: Gothenburg Sweden
|
| Quote: |
This could be helped using my BlockIP2 or the one from Roger.
Just my $0.02 |
I'm planning to use BlockIP2 for sure. Do not want them to get to the admin channels that I use. 
_________________
"Always code as if the guy who ends up maintaining your code will be
a violent psychopath who knows where you live." --Martin Golding |
|
| 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
|
|
|
|
