SendIpcMessage from service to usersession fails on 32 bit

[madshi]

Sorry for taking so long. Here's a fixed build:

http://madshi.net/madCollectionBeta.exe (installer 2.8.3.13)

[mdevoe]

I’m encountering a similar problem but mine is not related o 64 vs 32 bit. In my case, both my service and the queue owner running in a user session are 32 bits. In my case it seems to do with the elevation rights of the process creating the queue. I can also reproduce this by running one process with administrator privileges while the other process runs as a standard user. In short:

• WORKS: Elevated app creates IpcQueue and non-elevated app connects to it.
• WORKS: Both apps have the same elevation (either both non-admin or both admin)
• FAILS: Non-elevated app creates the IpcQueue, elevated app attempts to connect.

I’ve tried this with 3.1.18 and 4.1 and I still see the same problem.

In 4.1, I see a new security descriptor parameter but I don’t see it in the documentation.

Any thoughts or suggestions?

Thanks in advance.

[madshi]

The key problem here might be that the non-elevated app may not have the right to create a "global" queue. Which means only other processes within the same session will be able to see it.

Can you please check with Process Explorer which path the madCodeHook "ALPC Port" handle has in the non-elevated process?

[mdevoe]

Thanks for the quick response.

Hopefully this is the info you're looking for. When running as a standard (non-admin) rights, I find the following:

Name: \RPC Control\mchipc3516FT
Handle: 0x504
Access:0x001F0001
Object Address: 0xFFFFD83DE60FC90
Decoded Access: READ_CONTROL|DELETE|SYNCHRONIZE|WRITE_DAC|\WRITE_OWNER|<Unknown>

The "Name" above matches my IPC queue name of 3516FT

When running with elevated rights, all ALPC ports have values for "Decoded Access" identical to what is shown above.

TIA

[madshi]

That looks just fine to me. Does SendIpcMessage() fail even if you don't ask for a reply/answer?

[mdevoe]

SendIpcMessage works fine when not asking for a reply. This is true for an admin process sending a message to a non-admin process. However, expecting a reply causes it to hang on the admin process until the timeout expires. The non-admin queue owner never receives the message. It does not appear the callback is occurring. My solution requires I block the caller until the response comes back.

I’m considering named pipes as an alternative though it would be interesting to hear your thoughts or suggestions.

Thanks again.

[mdevoe]

My apologies, I once again reviewed this entire topic and failed to notice the "InitMadCHook" suggestion. I didn't think it would be related to IPC but it appears it does. I believe my solution is now behaving properly. Thanks so much for your quick replies and sorry for taking us down the wrong path.

[madshi]

Oh ok. So seems the SeCreateGlobalPrivilege privilege is there in the less privileged process, but not enabled by default.

[mdevoe]

Although I'll go ahead and call InitMadCHook in both processes, it appear only the admin process asking the non-admin process needs to call InitMadCHook.

Thanks again.