Thanks Neil; good suggestion. Question then is how important is it everytime we add a CSD or upgrade versions of MQ to recopy the new runmqtrm to a new mymqtrm. I gotta think the code on runmqtrm ain't changing anymore. Its not like we upgrade MQ versions constantly, and I will put a note in our upgrade doc, but a few years from now someone will forget that we did that. I wonder how important that is?
-----Original Message----- From: Neil Casey [mailto:[EMAIL PROTECTED] Sent: Thursday, July 22, 2004 10:11 PM To: [EMAIL PROTECTED] Subject: Re: Trigger Monitors (run under an ID other than mqm) Hi Peter, well done on getting this working, but you may want to consider copying the runmqtrm binary and renaming it, rather than changing the installed binary by altering the permissions. Some installation packaging features don't like it when the software you are upgrading doesn't exactly match what is expected, and I never feel comfortable changing the installed software config like that. I would look at "cp /opt/mqm/bin/runmqtrm /var/mqm/exits/mymqtrm; chmod 755 /var/mqm/exits/mymqtrm" and then use mymqtrm instead of runmqtrm. Regards, Neil Casey National Australia Bank Southern Star Technology WebSphere MQ Support 1/122 Lewis Rd Wantirna South office. +61 3 9886 2375 (x82375) mobile. +61 414 615 334 "Potkay, Peter M (ISD, IT)" <[EMAIL PROTECTED] To HARTFORD.COM> [EMAIL PROTECTED] Sent by: MQSeries cc List <[EMAIL PROTECTED] Subject n.AC.AT> Re: Trigger Monitors (run under an ID other than mqm) 23/07/2004 10:35 Please respond to MQSeries List <[EMAIL PROTECTED] n.AC.AT> Well, I got the default runmqtrm to run under another ID, and it kicks off processes under that ID as well. Those triggered processes truly are running under the new ID (not mqm), as they follow the rules I set with setmqaut, and doing a Q status shows the User ID connected is in fact the ID I want, not mqm. If I try and send the triggered app to a queue I did not give it authority to, it gets the 2035. All I did to get runmqtrm to run as mqappsaa, and any triggered process to run as mqappsaa, was the following. The triggered app should only be able to GET/PUT from SYSTEM.DEFAULT.LOCAL.QUEUE, no other queue: 1. Create a group called mqappsaa 2. Create a user called mqappsaa, and put him into the group mqappsaa 3. setmqaut -m SOLARIS1 -t qmgr -g mqappsaa +allmqi 4. setmqaut -m SOLARIS1 -t q -n SYSTEM.DEFAULT.INITATION.QUEUE -g mqappsaa +allmqi 5. setmqaut -m SOLARIS1 -t q -n SYSTEM.DEAD.LETTER.QUEUE -g mqappsaa +allmqi 6. setmqaut -m SOLARIS1 -t q -n SYSTEM.DEFAULT.LOCAL.QUEUE -g mqappsaa +allmqi 7. chmod 777 runmqtrm, so that anyone can start it. Probably can be tighter on this step, but you get the point. 8. log on as mqm, just to prove it will work even if I su to mqappsaa ######################################################### masun1 > su mqappsaa Password: $ whoami mqappsaa $ runmqtrm -m SOLARIS1 5724-B41 (C) Copyright IBM Corp. 1994, 2002. ALL RIGHTS RESERVED. WebSphere MQ trigger monitor started. __________________________________________________ Waiting for a trigger message /var/mqm/peterscript.sh 'TMC 2PETER End of application trigger. __________________________________________________ Waiting for a trigger message ######################################################################### 9. Open up another session, and check what ID runmqtrm is running under: masun1 > ps -ef|grep runmqtrm mqm 4160 3977 0 20:09:49 pts/3 0:00 grep runmqtrm mqappsaa 4145 4143 0 20:02:12 pts/2 0:00 runmqtrm -m SOLARIS1 10. Drop a test message into the triggered queue, and quickly do the following command to see what ID amqsget is running under. I triggered amqsget to run in the background. masun1 > ps -ef|grep amqsget mqm 4165 3977 0 20:20:09 pts/3 0:00 grep amqsget mqappsaa 4163 1 0 20:20:03 pts/2 0:00 /opt/mqm/samp/bin/amqsget SYSTEM1 A Queue Status on the INIT queue and the DLQ shows runmqtrm running as mqappsaa. A Queue Status on SYSTEM.DEFAULT.LOCAL.QUEUE shows amqsget running as mqappsaa, and it consumes the message. Switching the process def to run amqsget against SYSTEM.DEFAULT.LOCAL.QUEUEXXXXXX causes the app to get a 2035, proving security can be set on a triggered process started by the default runmqtrm. -----Original Message----- From: marty [mailto:[EMAIL PROTECTED] Sent: Saturday, July 10, 2004 8:33 AM To: [EMAIL PROTECTED] Subject: Re: Trigger Monitors Peter, >Can't you start the TM under another ID in the first place, like this? > >/usr/bin/su - mqappid -c "/opt/mqm/bin/runmqtrm -m MYQMname -q >APP.INIT.QUEUE" & > >Wouldn't this cause the TM to run as mqappid, and then any process it >started would also run as mqappid? > > World has no permissions by default so only root and user mqm or group mqm members can start it (mqappid would need to be a member of group mqm). Regardless of who starts runmqtrm, since it is setuid (and setgid) mqm it will run with effective id mqm and effective group mqm, as will any triggered program. Plus, mqappid being a member of group mqm is probably not a good thing. If you unset setuid (and setgid), as Greg suggested in (b) (possibly leaving group mqm as owner and giving world r-x) then it will run as whomever starts it, as will any triggered programs. That allows any user to run the trigger monitor but the object authorities will determine if it can actually work. The MQ permissions need to be set so that the user's group(s) has permissions necessary to run the trigger monitor successfully. I forget exactly what the required settings are but something like get+inquire on the inititiation queue and display on the process. I think a benefit of settings "-r-xr-xr-x mqm mqm", as opposed to "-r-xr-x--- mqm mqapps" (see Greg's solution b), would be more control of which groups could listen to which initq(s) and start which process(es) instead of lumping them all into one group with common permissions. Depends on requirements - I guess that'd be more flexible but entail a bit more administrivia. Having all triggered programs run as user/group mqm can be problematic though not nearly as bad as running them as root :-) One issue is you probably don't want to give away mqm rights so readily. Another is mqm often doesn't have rights to either start the triggered app or do something the app is supposed to do. Yet another arises when you use the client trigger monitor and hopefully enforce clients attach as a user other than mqm. I believe a problem with Dennis' suggestion is you cannot su in a script/program unless you are root and you never want to run the trigger monitor, nor anything else you don't have to, as root. I think a non-root issued su requires the password to be entered on a tty so you can't redirect one in or anything like that - assuming you'd even want to. To not answer Greg's question I have no idea why runmqtrm is setuid/setgid but it would be interesting to find out. It's been that way for a very long time and I'm sure there is, or was, a logical reason. I've used Greg's solution (a) before but seems like (b) would be better so you don't lose track of all those trigger monitor programs. Don't know if there's a (c), outside of something like a custom trigger monitor running as root that can switch effective user/group before the system() call but that doesn't sound like a great idea. Maybe the list will come up with a good answer for (c) - the optimal approach. Just thought of one possible approach - leave runmqtrm as it is and setuid/setgid the triggered applications to appropriate values. One drawback to that is devious app owners could, depending on permissions, unset setuid/setgid so they get mqm rights. mqm would have to be in the group that owns the app too, if it's not world executable. Oh well, it might work. Hope that helps the discussion some and didn't introduce much misinformation. Cheers, Marty Hi Greg, how are things at Pioneer? Heard from Rob Rehms lately? > >-----Original Message----- >From: Miller, Dennis [mailto:[EMAIL PROTECTED] >Sent: Friday, July 09, 2004 6:21 PM >To: [EMAIL PROTECTED] >Subject: Re: Trigger Monitors > > >I think it's not so much the trigger monitor runs under MQM as that the >triggered applications also inherit that userid. Since the mqadmin can >tightly control what programs the trigger monitor can run, you might >consider a scheme where the trigger monitor runs shell scripts that SU >to a more appropriate userid before getting on with business logic. > >Regards, >Dennis > >-----Original Message----- >From: Smith, Gregory [mailto:[EMAIL PROTECTED] >Sent: Friday, July 09, 2004 11:47 AM >To: [EMAIL PROTECTED] >Subject: Trigger Monitors > > >I'm posting this here for discussion and will likely open a PMR with IBM >to get their perspective. > >In the UNIX realm for a while we have discussed the fact we are not >comfortable triggering an application and having it run as mqm with full >mqm privileges. We would prefer and are considering having multiple >trigger monitors each running under a unique application group id. > >Naturally out of the box the trigger monitors attributes are set to >force the monitor to run as mqm as the example below shows: > > lx03-cluster:#> ls -al /opt/mqm/bin/run* > -r-sr-s--- 1 mqm mqm 18328 Feb 11 16:09 >/opt/mqm/bin/runmqtmc > >#1 - Is anyone aware of a technical reason for this? > >We are considering two approaches to this > >a) Placing a copy of the executable in each application groups home >directory. The down side to this is we could have many versions that we >as admins would have to keep track of whenever we apply maintenance to >the software. > >b) Modifying the attributes of the source > > -r-xr-x--- 1 mqm mqapp 18328 Feb 11 16:09 >/opt/mqm/bin/runmqtmc > > but again we would need to keep note of this whenever we apply >maintenance to the software however this would be the lesser of the two >evils. > >c) are there other options?? > >Thanks for your input in advance! > >Gregory P. Smith >Pioneer, A DuPont Company >E-Mail: No SPAM:[EMAIL PROTECTED] >Phone: 515-253-2468 > 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 This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. 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
