Gregory,
There are others who do run the trigger monitor under a userid other than
root. I have an old posting that discusses this (see below). As for your
questions:
1. Ask IBM. It's their product and they would know what the original
thought was behind using mqm.
2. See posting below (and others on the list will probably have other ideas
as well).
To: [EMAIL PROTECTED]
cc: (bcc: Richard Tsujimoto/CHASE)
From: Brian Shelden <[EMAIL PROTECTED]>
Date: 02/05/98 02:44:51 PM GMT
Subject: Re: Unix Trigger Monitor
>On Unix, triggered processes run under the same ID that the trigger
monitor is
>started with. This will be a problem at our shop, particularly with
processes
>that will connect to Oracle (just about all of them). Our DBAs will insist
on
>some way to differentiate Oracle threads.
>
>So... I'm thinking about changing the sample trigger monitor source
>(amqstrg0.c). I thought I could place the ID to be used in the envrdata
>attribute of the process definition. Then, instead of the monitor starting
the
>command by using system(<applicid>), I would use:
> system(su - <envrdata> "-c <applicid>")
>This ought to work as long as the monitor is started as root.
I don't know about the envrdata issue. However, you might want to
rethink running the trigger monitor as root. If all you're trying
to do is get a program to run as a particular user, why not set the
application to run setuid?
a) it's really easy (chmod u+s <applicid>) b) you don't need to
change the trigger monitor nor your application, and c) running the
trigger monitor as root exposes some serious security holes in
your system.
There are other ways to do this, too. But in it general, it's a
bad idea to run anything as root that doesn't need it--especially
a program whose job it is to run other programs.
--Brian T. Shelden Certified MQSeries Specialist
[EMAIL PROTECTED] IBM Global Services
(914) 759-2348 (T/L 248) Sterling Forest, NY 10979
"Smith, Gregory"
<[EMAIL PROTECTED]
ONEER.COM> To
Sent by: MQSeries [EMAIL PROTECTED]
List cc
<[EMAIL PROTECTED]
n.AC.AT> Subject
Trigger Monitors
07/09/2004 02:47
PM
Please respond to
MQSeries List
<[EMAIL PROTECTED]
n.AC.AT>
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
This communication is for use by the intended recipient and contains
information that may be privileged, confidential or copyrighted under
applicable law. If you are not the intended recipient, you are hereby
formally notified that any use, copying or distribution of this e-mail,
in whole or in part, is strictly prohibited. Please notify the sender
by return e-mail and delete this e-mail from your system. Unless
explicitly and conspicuously designated as "E-Contract Intended",
this e-mail does not constitute a contract offer, a contract amendment,
or an acceptance of a contract offer. This e-mail does not constitute
a consent to the use of sender's contact information for direct marketing
purposes or for transfers of data to third parties.
Francais Deutsch Italiano Espanol Portugues Japanese Chinese Korean
http://www.DuPont.com/corp/email_disclaimer.html
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
