A customer reported that they had a system where multiple processes share a mutex. Each process calls CreateMutex
to create the mutex or obtain a handle to the existing one. But the customer found that sometimes, the call to CreateMutex
fails, and GetLastError
reports that the reason is ERROR_ACCESS_DENIED
. What could cause that?
Specifically, the two processes are a UI process and a service. Both processes use CreateMutex
to create or access the mutex, passing NULL
as the security attributes.
Okay, so issue is that the two processes are running under different identities with different privileges. Even though you think you are creating the mutex in both places with the same security attributes (because you’re passing NULL
both times), the effect of the NULL
is different depending on who is calling.
What’s probably happening is that most of the time, the mutex is created by the UI process first, so the mutex gets the access control list that grants access to the user under which the UI process is running, and to the SYSTEM account, The service is running under the SYSTEM account, so it gets access.
But once in a while, it’s the service that creates the mutex first. In that case, the access control list on the mutex grants access only to the SYSTEM account, in which case the UI process cannot access the mutex.
The customer reported that they saw this behavior only on builds 14393 and higher and were wondering what could be causing it. My guess is that something is happening on build 14393 that wakes up the service sooner than it used to, causing the service to be the one to create the mutex, and that’s what’s preventing the UI process from gaining access.
In these sorts of cases, where two processes with different permissions need to share a securable object, the general principle is to have the high-permission process create the object and set the permission so that the low-permission process can access it. If you let the low-permission process be the one that creates the mutex, then you have a potential squatting attack.
0 comments