| Author |
Message
|
| jwendorf |
 Posted: Fri May 09, 2003 7:53 am Post subject: Userid access - Windows/XP |
 |
|
Acolyte
Joined: 15 May 2001
Posts: 63
Location: Madison, WI
|
One of our developers is asking how the userid is obtained with MQseries
and if it is cached.
JW |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Fri May 09, 2003 8:07 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
The userid in MQSeries is obtained the same way any other process under Windows XP obtains a userid.
But you need to be more specific with your question. Does your developer want to know
1) What userid his program passes to MQSeries for authentication/authorization?
2) What userid is used when he PUTS a message?
3) What userid PUT the message that his program is GETTING?
Also, what kind of 'caching' are you asking about? |
|
| Back to top |
|
|
| jwendorf |
| Posted: Fri May 09, 2003 8:39 am Post subject: |
|
|
Acolyte
Joined: 15 May 2001
Posts: 63
Location: Madison, WI
|
The developer's application is using web services. When the application
does a connect to MQ and the web.config file has a userid that is not valid,
the application receives a 2035. A valid userid is then put in the
web.config file. When the application does the connect, the first userid is used by MQ again(verified this with a MQ trace), not the second userid.
JW |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri May 09, 2003 8:47 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
This sounds like an issue with caching going on either inside the application or inside your application server. MQSeries doesn't do anything like cache the last userid that connected from a particular IP address.
Does your application know to reload the web.config file?
Is your application using any sort of MQSeries connection pooling? |
|
| Back to top |
|
|
| Pann |
| Posted: Sun Jun 15, 2003 8:45 am Post subject: |
|
|
Newbie
Joined: 15 Jun 2003
Posts: 3
|
MQ does infact cache the user id.
It uses the uid from the very first MQCONN for that process id and uses it thoughout, even i belive, if you do a MQDISC.
The solution is to ensure that you do the MQCONN for each user inside a new thread or process and after the setuid or ImpersonateLoggedOnUser.
If you're using windows, you'll have problems doing a fork / exec so threads are problably your solution.
Interestingly though, I've only seen the caching on unix.
_________________
MQ Testing and Analysis tools.
www.mqspy.com |
|
| Back to top |
|
|
| mqonnet |
| Posted: Sun Jun 15, 2003 10:24 am Post subject: |
|
|
Grand Master
Joined: 18 Feb 2002
Posts: 1114
Location: Boston, Ma, Usa.
|
Pann, i would differ with you here.
Jeff was right, MQ Does NOT do any chaching of any type. MQ in fact has the overhead of authenticating the userid on each Api call rather than just the Conn. It achieves this NOT by caching the userid, but by passing over the userid each time you make an api call.
You may say that it stores the userid internally but DOES in NO Way cache it.
But yes, each conn would always invoke the underlying api with the userid who is trying to connect.
As for the original problem. You must provide more details that this. Are you connecting to mq using server or client libraries. Is the app threaded. Do you use context information in your app.
Cheers
Kumar |
|
| Back to top |
|
|
| jwendorf |
| Posted: Mon Jun 16, 2003 6:10 am Post subject: |
|
|
Acolyte
Joined: 15 May 2001
Posts: 63
Location: Madison, WI
|
This is they reply that IBM has provided. MQ caches the userid on process startup, and that cache is only refreshed on certain circumstances. The apar(IC36402) that we applied has solved the problem.
This is the description that is included in the apar:
Customer runs client app under IIS, were the userid SYSTEM,
which is what the process starts running as. Since MQ caches
the userid on process startup, and that cache is only refreshed
on certain circumstances. The code should change to update that
cached information on a non-shared mqconn call. |
|
| Back to top |
|
|
| Pann |
| Posted: Mon Jul 07, 2003 4:27 pm Post subject: |
|
|
Newbie
Joined: 15 Jun 2003
Posts: 3
|
|
| Back to top |
|
|
| mqonnet |
| Posted: Tue Jul 08, 2003 4:57 am Post subject: |
|
|
Grand Master
Joined: 18 Feb 2002
Posts: 1114
Location: Boston, Ma, Usa.
|
Pann,
If you post your test cases with the MQ version and platform, i can assess further. But in any case, if you are calling the MQI from regular client or server app the userid that comes in is stored locally in one of the structures and that structure is used at all times for further authentication. There is NO caching of any sort under these circumstances.
Cheers
Kumar |
|
| Back to top |
|
|
| Pann |
| Posted: Tue Jul 08, 2003 5:49 am Post subject: |
|
|
Newbie
Joined: 15 Jun 2003
Posts: 3
|
I'm afraid I can't post the code because it's part of our test suite.
But you should be able to duplicate on *nix with 2 users. One with mqm access, the other with no access (verify with dspmqaut). Below is pseudo code from this test case.
From within the same process.
If you set the effective user Id to the user without mqm authority and MQCONN.
Then change effective user Id to a user without mqm authority and do another MQCONN, that MQCONN will succeed even though they don't have the auth. It will connect with the effective user id of the first user to call MQCONN.
You'll probably have to run as a setuid root process and change back to root between the changes to different users.
Also if you try it the otherway around. MQCONN with out authority for that principle and then MQCONN as a user with authority. The second one will fail even though they have authority, but failed because it's using the initial connections identity.
This is all confirmed by PTF IC36402.
_________________
MQ Testing and Analysis tools.
www.mqspy.com |
|
| Back to top |
|
|
| mqonnet |
| Posted: Tue Jul 08, 2003 2:31 pm Post subject: |
|
|
Grand Master
Joined: 18 Feb 2002
Posts: 1114
Location: Boston, Ma, Usa.
|
I shall try when i get a chance. But if you could give me specifics, i can deal with this better.
Like What the test app does. What calls does it make in what order under what userid. If you can take an example and explain the same that would be better.
Cheers
Kumar |
|
| Back to top |
|
|
|
|
