I'm thinking more of the alias queue being the same name as the destination queue and there are multiple destination qeues of the same name. BB.
-----Original Message----- From: Ruzi R [mailto:[EMAIL PROTECTED] Sent: Monday, 01 December, 2003 16:15 To: [EMAIL PROTECTED] Subject: Re: FW: Cluster queue security You give the authority to the alias queue that is defined locally (that is not clustered). I think it is a neat way of giving access to the cluster queues. The user will have access to the cluster queue via the alias queue, and will be unable to access the cluster queue directly. The same applies to an alias queue resolving to a local queue (not cluster) on the same qmgr. Best regards, Ruzi --- Bruce Barclay <[EMAIL PROTECTED]> wrote: > In the example described, which queue gets the > authority set, Q1 the alias > or Q1 the local or both??? Isn't it dangerous to > have the same name for > alias' as for local queues in a cluster > environment?? BB. > > -----Original Message----- > From: Ruzi R [mailto:[EMAIL PROTECTED] > Sent: Monday, 01 December, 2003 13:44 > To: [EMAIL PROTECTED] > Subject: Re: Cluster queue security > > > Hi Paul, > > > But my tests seems to show that if I create a > local > > QAlias which resolves to a Cluster queue, I can > > permit access to this queue *without* needing to > > grant access to the Cluster xmit queue and thus > open > > up the whole cluster. > > > > I haven't seen this mentioned anywhere which makes > > me think that perhaps I have missed something. > > You have not missed anything. The following excerpt > from the Cluster manual states exactly what you > have > mentioned above: > > It is possible to avoid the need to give general > access to all cluster resources and > +Put access to the transmit queue. You do this by > defining alias or remote queue > definitions on your machine which resolve to queues > in > the cluster, and giving the > appropriate authority for access to these instead of > the cluster transmit queue. For > example, suppose there is a queue called Q1 in the > clusters to which your queue > manager CORK belongs. If you > DEFINE QALIAS(Q1) TARGQ(Q1) DEFBIND(NOTFIXED) > and then > etmqaut -m CORK -t qmgr -p GUEST +connect > etmqaut -m CORK -t queue -n Q1 -p GUEST -all +put > > The user GUEST would only be able to send messages > to > the cluster queue Q1. > Note that it is not possible to use the same > technique > for a queue manager alias, > because this requires access to the underlying > SYSTEM.CLUSTER.TRANSMIT.QUEUE queue. > > Best regards, > > Ruzi > > --- Paul Meekin <[EMAIL PROTECTED]> wrote: > > Hi all, > > > > I've been doing some work on trying to secure our > > cluster queues. From the Clusters manual: > > > > "[On non-z/Os systems] you cannot restrict access > to > > individual queues that do not exist on your queue > > manager. However, you can restrict access to all > the > > queues in a cluster." > > > > You do this by granting or restricting the > userid's > > access to SYSTEM.CLUSTER.TRANSMIT.QUEUE as has > been > > discussed before. > > > > But my tests seems to show that if I create a > local > > QAlias which resolves to a Cluster queue, I can > > permit access to this queue *without* needing to > > grant access to the Cluster xmit queue and thus > open > > up the whole cluster. > > > > I haven't seen this mentioned anywhere which makes > > me think that perhaps I have missed something. > > > > Any thoughts would be appreciated. > > > > Cheers, > > Paul > > > > > > > > > ******************************************************** > > > > This e-mail is sent by Energis Communications > > Limited and its contents are > > confidential and may be legally privileged. > > > > > ******************************************************** > > > > Instructions for managing your mailing list > subscription are provided in > the Listserv General Users Guide available at > http://www.lsoft.com > Archive: http://vm.akh-wien.ac.at/MQSeries.archive > > Instructions for managing your mailing list > subscription are provided in > the Listserv General Users Guide available at > http://www.lsoft.com > Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
