I'm sorry - I took the documentation to mean that for non-Java clients, on Windows and UNIX, the userid in the MQCD is the currently logged on user and that the environment variables are not referencved. So if I could verify that it was not a Java client, then I could rely on the userid to be the real user.
Peter Heggie -----Original Message----- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Wyatt, T. Rob Sent: Monday, January 05, 2004 11:56 AM To: [EMAIL PROTECTED] Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users Peter, If you could do that, what would it gain you? In general you want ALL client connections to use low-privileged IDs or else they have full administrative rights to the QMgr. It is trivial on Java and not too much harder in other languages to specify any ID - mqm for instance - to the client MCA. Since the client can assert any ID, why would you trust some types of client and not others? -- T.Rob -----Original Message----- From: Heggie, Peter [mailto:[EMAIL PROTECTED] Sent: Monday, January 05, 2004 11:11 AM To: [EMAIL PROTECTED] Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users Here is an excerpt from the doc (Clients/Chapter 7) >>> Access control in WebSphere MQ is based upon the user identifier associated with the process making MQI calls. For WebSphere MQ clients, the process that issues the MQI calls is the server-connection MCA. The user identifiers used by the server-connection MCA are that contained in the MCAUserIdentifier and LongMCAUserIdentifier fields of the MQCD. The contents of these fields are determined by: - Any values set by security exits - The user ID (for clients on UNIX systems, Windows 2000, Windows NT, and Windows XP ) or MQ_USER_ID environment variable (for other clients) from the client. - MCAUSER (in the server-connection channel definition). Depending upon the combination of settings of the above, the user-identifier fields are set to appropriate values. If a server-connection security exit is provided, the user-identifier fields can be set by the exit. Otherwise they are determined as follows: If the server-connection channel MCAUSER attribute is nonblank, this value is used. If the server-connection channel MCAUSER attribute is blank, the user ID received from the client is used. However, for the clients that use the MQ_USER_ID environment variable to supply the user ID, it is possible that no environment variable is set. In this case, the user ID that started the server-connection channel is used. For Java client connections, if the client application does not provide a user ID then no client user identification is provided to the server. <<< Looking at a server connection channel, I see the MCA userid field is blank, but the connection is coming from a Windows XP machine. I would have thought, based on the documentation above that, except for Java client apps, for the UNIX and Windows (W2k, NT, XP) clients that the logged on userid is automatically placed in the MCA UserID field. But I guess not. It is only placed in the MQCD exit block, available for an exit to place the contents in the MCA User field. Has anyone figured out how to determine if an incoming connection is coming from a Java client? Peter Heggie -----Original Message----- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Wyatt, T. Rob Sent: Monday, January 05, 2004 10:50 AM To: [EMAIL PROTECTED] Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users Benjamin, That is because the channel used by the client is using the authority of the QMgr. Unless you put an MCAUSER or a security exit that substitutes a different UserID on the channel, you will get administrative rights. This is true of all client-connections and, yes, it is dangerous. -- T.Rob 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 e-mail and any files transmitted with it, are confidential to National Grid and are intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error, please reply to this message and let the sender know. 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
