RE: MQ and adopted authority

Hi Martin

thanks for taking the time to reply.

I had an inkling that this would be the answer  - I will get that Redbook 
but I'll log onto the site and get it myself (I appreciate the offer though:))

I guess since the particular group of queues I have given *PUBLIC will be 
used by pretty much  everyone then *public is apropriate. This particular 
portion of the application is intended to be replaced so I can live with it 
for a short while.

I dunno about giving everyone QMQMADM - that seems a little risky, but 
certainly the group profile aproach is what I had in mind to get around 
this - it just seemed like I was doing it twice, once in OS/400 and once in MQ.

I had another strange one yesterday, a program I wrote to start MQ in batch 
failed with a message that it was "not authorised" to the command. This is 
despite the fact that the program was owned by a God profile, and the 
program adopted owner authority. Again I've worked around it (production 
facility to keep running) but this bears further investigation.

Some of the things the AS/400 was built on seem to be going like system 
wide security you could count on, and predictable security behaviour. I 
guess the above command may be documented as one of the commands that don't 
respect adopted security, but once you get to a certain number it's not a 
case of being "documented exceptions" any more, its a case of being 
"broken" IMO at least.

Cheers
Evan Harris




>Evan Harris said:
>
> > I have a client running V4R5 who just upgraded MQ from V4R2M1 to V5R2.
> >
> > Some processes that previously worked now seem to exhibit
> > some different
> > behaviour and I'm wondering if MQ 5.2 treats adopted authorities any
> > differently.
>
>I'm not sure about adoption, but the whole authority structure _is_
>handled differently from V5R1 of MQSeries onwards.  The way we've been
>treating it, in our development environment, is that any user that
>wishes to use MQSeries has to be a member of the QMQMADM group.  This
>can be either as their group profile or as a supplemental group.  It
>looks like there are other ways to approach it, though.
>
>I have a downloaded PDF from IBM called "Migrating to MQSeries for
>AS/40, V5.1" which you (or your client) might want to read.  I don't
>have the URL for it to hand, but I don't think we'll be violating any
>licences if you contact me off-list and I email it to you.  In the
>meantime here's a quick quote:
>
>Chapter 7. Security
>
>Security for MQSeries for AS/400 changes significantly with V5.1.
>Security with
>V5.1 is implemented using the MQSeries Object Authority Manager (OAM).
>
>The OAM manages users' authorizations to manipulate MQSeries objects,
>including
>queues and process definitions. It also provides a command interface
>through
>which you can grant or revoke access authority to an object for a
>specific group of
>users. The decision to allow access to a resource is made by the OAM,
>and the
>queue manager follows that decision. If the OAM cannot make a decision,
>the
>queue manager prevents access to that resource.
>
>With the OAM, you are able to control access to MQSeries objects through
>the
>MQI. When an application program attempts to access an object, the OAM
>checks
>that the user profile making the request has the authorization for the
>operation
>requested. This enables different groups of users different kinds of
>access
>authority to the same object. For example, for a specific queue, one
>group may be
>allowed to perform both put and get operations, while another group may
>be
>allowed only to browse the queue.
>During installation the following user profiles are created:
>
>QMQM
>Primarily used for internal product-only function
>
>QMQMADM
>Intended to be used as a group profile for administrators of MQSeries,
>giving
>access to CL commands and MQSeries resources
>
>Cheers,
>
>Martin.
>
>--
>Martin McCallion
>Midas-Kapiti International
>Work:  mccallim@midas-kapiti.com
>Home: martin.mccallion@ukonline.co.uk
>
>Apologies for the length of this sig, but company policy says:
>This email message is intended for the named recipient only.  It may be
>privileged and/or confidential.  If you are not the intended named
>recipient of this email then you should not copy it or use it for any
>purpose, nor disclose its contents to any other person.  You should
>contact Midas-Kapiti International as shown below so that we can take
>appropriate action at no cost to yourself.
>
>Midas-Kapiti International Ltd, 1 St George's Road, Wimbledon, London,
>SW19 4DR, UK
>Email: Postmaster@midas-kapiti.com Tel: +44 (0)208 879 1188 Fax: +44
>(0)208 947 3373
>Midas-Kapiti International Ltd is registered in England and Wales under
>company no. 971479
>+---
>| This is the Midrange System Mailing List!
>| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
>| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
>| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
>| Questions should be directed to the list owner/operator: david@midrange.com
>+---

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---