Re: QueueUserAPC and thread secuirty, a problem.
- From: Sergei Zhirikov <sfzhi@xxxxxxxxx>
- Date: Fri, 21 Nov 2008 13:07:08 +0100
Hugo gleaves@xxxxxxxxxxx> <hugh wrote:
"Sergei Zhirikov" wrote:
Hugo gleaves@xxxxxxxxxxx> <hugh wrote:HiI'm wondering where you got the idea that NULL DACL gives access to everyone. I can't remember any piece of documentation that states or even implies that.
We have code that uses QueueUserAPC to queue work to a thread in another process. This works fine if both processes are running under same account.
However when run under different accounts, we get "Access Denied" in the "sender" application when it attempts to OpenHandle to the target processes thread (it has the thread ID incidentally).
What is odd, is that we pass a security descriptor with a NULL DACL into CreateThread when the "receiver" creates the thread.
My understanding is that a security descriptor with a NULL DACL pretty much grants all access to everyone, not a great idea but true nevertheless. We actually use the very same security descriptor (it's a static variable in the library actually) in CreateMutex, CreateFileMapping and these ARE accessible to other processes running under other user IDs.
We tried OpenThread with THREAD_ALL_ACCESS and THREAD_SET_CONTEXT but always get access denied and thus no handle returned.
Does anyone have any insights into how to address this issue?
Thanks
H
http://msdn.microsoft.com/en-us/library/ms682453(VS.85).aspx
"The lpSecurityDescriptor member of the structure specifies a security descriptor for the new thread. If lpThreadAttributes is NULL, the thread gets a default security descriptor. The ACLs in the default security descriptor for a thread come from the primary token of the creator."
and more on the same page:
"If a security descriptor is not provided when the thread is created, a default security descriptor is constructed for the new thread using the primary token of the process that is creating the thread. When a caller attempts to access the thread with the OpenThread function, the effective token of the caller is evaluated against this security descriptor to grant or deny access."
I hope this answers your question.
Hi.
I got it from here:
http://msdn.microsoft.com/en-us/library/aa379286(VS.85).aspx
perhaps you are confusing a NULL DACL with a NULL security descriptor pointer?
We DO supply a security descriptor (i.e. we dont pass a NULL pointer) but that secuirty descriptor is (reffred to as) a NULL DACL, because it has no ACL entries.
This is how you tell Windows explicitly that you "dont care about access".
H
You are right, I misunderstood your description of the problem, sorry.
I suspect that thread access rights may be related to process access rights somehow. For example, if you have all permissions to access a file you still can't access it unless you also have certain permissions to access its parent directory (or a privilege to bypass those checks). This is pure speculation, I can't find any documentation to confirm it, but if I were you I would first check the security descriptor of the thread you have just created to make sure it is what you expect. You could also try to change the security descriptor of the process to allow all access to everyone, just as an experiment, to see if it makes any difference.
.
- Follow-Ups:
- Re: QueueUserAPC and thread secuirty, a problem.
- From: Hugo gleaves
- Re: QueueUserAPC and thread secuirty, a problem.
- References:
- QueueUserAPC and thread secuirty, a problem.
- From: Hugo gleaves
- Re: QueueUserAPC and thread secuirty, a problem.
- From: Sergei Zhirikov
- Re: QueueUserAPC and thread secuirty, a problem.
- From: Hugo gleaves
- QueueUserAPC and thread secuirty, a problem.
- Prev by Date: Re: QueueUserAPC and thread secuirty, a problem.
- Next by Date: RE: QueueUserAPC and thread secuirty, a problem.
- Previous by thread: Re: QueueUserAPC and thread secuirty, a problem.
- Next by thread: Re: QueueUserAPC and thread secuirty, a problem.
- Index(es):
Relevant Pages
|