I am trying to queue and APC, using function QueueUserAPC. The second parameter of the function is hThread which must have a THREAD_SET_CONTEXT access right. In CreateThread function how do I set this access right in LPSECURITY_ATTRIBUTES ?
The returned handle from CreateThread or GetCurrentThread should already grant all access.
You should only need to muck with the security descriptor if someone else will be opening a handle to the thread using the thread id.
- S
-----Original Message-----
From: xxxxx@hotmail.com
Sent: Thursday, April 09, 2009 22:58
To: Windows System Software Devs Interest List
Subject: [ntdev] Setting security attributes in thread
I am trying to queue and APC, using function QueueUserAPC. The second parameter of the function is hThread which must have a THREAD_SET_CONTEXT access right. In CreateThread function how do I set this access right in LPSECURITY_ATTRIBUTES ?
—
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
thanks for your reply.
What I am trying to do is, creating a thread in process A, and then passing this thread handle (through pipe) to process B, which will queue the apc in process A using that thread handle. This brings another doubt to my mind.
Does a thread handle remain valid in context of other process ?
If not, then the right way to do it must be passing thread id, and then using that id to open thread handle in other process. In that case I need to modify security descriptor, which seems complex.
Not without some effort on your part. It’s possible to have a child process inherit handles, and
DuplicateHandle() can be used to share handles, but the details of how to do this have faded from my
memory in the many years since I’ve last done something like this; a thread id is indeed valid
system wide.
Good luck,
mm
xxxxx@hotmail.com wrote:
thanks for your reply.
What I am trying to do is, creating a thread in process A, and then passing this thread handle (through pipe) to process B, which will queue the apc in process A using that thread handle. This brings another doubt to my mind.
Does a thread handle remain valid in context of other process ?
If not, then the right way to do it must be passing thread id, and then using that id to open thread handle in other process. In that case I need to modify security descriptor, which seems complex.
If the other process is running as the same user as the first process then
there is no security descriptor issue.
If you want to pass the handle in the pipe then you need a handle to the
second process in order to duplicate the thread handle. If your application
started the second process then you already have that handle.
Bill Wandel
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com]
On Behalf Of xxxxx@hotmail.com
Sent: Friday, April 10, 2009 7:54 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Setting security attributes in thread
thanks for your reply.
What I am trying to do is, creating a thread in process A, and then passing
this thread handle (through pipe) to process B, which will queue the apc in
process A using that thread handle. This brings another doubt to my mind.
Does a thread handle remain valid in context of other process ?
If not, then the right way to do it must be passing thread id, and then
using that id to open thread handle in other process. In that case I need to
modify security descriptor, which seems complex.
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Overall, this design is very dangerous. You don’t want another process to mess with the first process execution flow.
I suggest to rethink the design using window messages or message pipes, or other means of messaging.
The two processes that I am using are two different processes created independently. (No parent child relationship b/w them).
@MM & @Bill
I tried to use the DuplicateHandle way duplicate a handle of process A for process B. But for DuplicateHandle to work, the process should have PROCESS_DUP_HANDLE access right. For that I again need to modify security descriptor for the process.
@Alex
Thanks. I will reconsider the design. But since the issue has come up, I would try to solve it. Will learn new things in the process 
I am pretty sure that the default SD on the process includes
PROCESS_DUP_HANDLE. This all assumes that the second process is running
under the same user as the first process.
As has been already pointed out, there are much better ways of interprocess
communications then using APSs. Why can’t you use named pipes or RPC or COM?
Bill Wandel
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com]
On Behalf Of xxxxx@hotmail.com
Sent: Saturday, April 11, 2009 1:53 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Setting security attributes in thread
The two processes that I am using are two different processes created
independently. (No parent child relationship b/w them).
@MM & @Bill
I tried to use the DuplicateHandle way duplicate a handle of process A for
process B. But for DuplicateHandle to work, the process should have
PROCESS_DUP_HANDLE access right. For that I again need to modify security
descriptor for the process.
@Alex
Thanks. I will reconsider the design. But since the issue has come up, I
would try to solve it. Will learn new things in the process
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
I’m not sure that that’s necessarily true, depending on the version of the os you’re running on and
depending on how/by whom the process was created.
I believe that in order to obtain a handle to another process with full access rights, you need to
enable SeDebugPrivilege in that process.
If you’re dealing with a protected process, DuplicateHandle() will not work. I’m not sure what you
would do in that case from user mode.
Bill Wandel wrote:
I am pretty sure that the default SD on the process includes
PROCESS_DUP_HANDLE. This all assumes that the second process is running
under the same user as the first process.
As has been already pointed out, there are much better ways of interprocess
communications then using APSs. Why can’t you use named pipes or RPC or COM?Bill Wandel
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com]
On Behalf Of xxxxx@hotmail.com
Sent: Saturday, April 11, 2009 1:53 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Setting security attributes in threadThe two processes that I am using are two different processes created
independently. (No parent child relationship b/w them).@MM & @Bill
I tried to use the DuplicateHandle way duplicate a handle of process A for
process B. But for DuplicateHandle to work, the process should have
PROCESS_DUP_HANDLE access right. For that I again need to modify security
descriptor for the process.@Alex
Thanks. I will reconsider the design. But since the issue has come up, I
would try to solve it. Will learn new things in the process
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminarsTo unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
SeDebugPrivilege turns off the access check when opening a process or thread handle, nothing more. There aren’t any access rights granted by that mechanism which wouldn’t be granted with the proper ACLs in a security descriptor.
The default security descriptor should grant GENERIC_ALL to the creator’s SID, as well as access for localsystem and administrators.
- S
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Martin O’Brien
Sent: Saturday, April 11, 2009 3:57 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Setting security attributes in thread
I’m not sure that that’s necessarily true, depending on the version of the os you’re running on and
depending on how/by whom the process was created.
I believe that in order to obtain a handle to another process with full access rights, you need to
enable SeDebugPrivilege in that process.
If you’re dealing with a protected process, DuplicateHandle() will not work. I’m not sure what you
would do in that case from user mode.
Bill Wandel wrote:
I am pretty sure that the default SD on the process includes
PROCESS_DUP_HANDLE. This all assumes that the second process is running
under the same user as the first process.
As has been already pointed out, there are much better ways of interprocess
communications then using APSs. Why can’t you use named pipes or RPC or COM?Bill Wandel
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com]
On Behalf Of xxxxx@hotmail.com
Sent: Saturday, April 11, 2009 1:53 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Setting security attributes in threadThe two processes that I am using are two different processes created
independently. (No parent child relationship b/w them).@MM & @Bill
I tried to use the DuplicateHandle way duplicate a handle of process A for
process B. But for DuplicateHandle to work, the process should have
PROCESS_DUP_HANDLE access right. For that I again need to modify security
descriptor for the process.@Alex
Thanks. I will reconsider the design. But since the issue has come up, I
would try to solve it. Will learn new things in the process
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminarsTo unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
If both the QueueUserApc caller and the CreateThread caller runs under the same user context - then you do not need to do anything.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
wrote in message news:xxxxx@ntdev…
>I am trying to queue and APC, using function QueueUserAPC. The second parameter of the function is hThread which must have a THREAD_SET_CONTEXT access right. In CreateThread function how do I set this access right in LPSECURITY_ATTRIBUTES ?
>
>
> Does a thread handle remain valid in context of other process ?
DuplicateHandle is a must.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
>If both the QueueUserApc caller and the CreateThread caller runs under the same user context - then >you do not need to do anything.
Yes its true. THREAD_SET_CONTEXT access right is already there, and I was successfully able to queue the apc.
In fact when we use OpenThread (…) we can specify the access rights that we need (from those that are available).
DuplicateHandle is a must.
I realized this too. Earlier what I was doing was, sending the handle directly from process A to B and was using that handle in process B. The correct approach was to send thread_id, and use it to open the handle and then use the handle.
Why does a handle become invalid in context of other process?
> Why does a handle become invalid in context of other process?
Handles are maintained per app, not per user or per session. If this is a surprise to you, stop now an educate yourself with some reading / training materials
d
Sent from my phone with no t9, all spilling mistakes are not intentional.
-----Original Message-----
From: xxxxx@hotmail.com
Sent: Monday, April 13, 2009 5:24 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Setting security attributes in thread
>If both the QueueUserApc caller and the CreateThread caller runs under the same user context - then >you do not need to do anything.
Yes its true. THREAD_SET_CONTEXT access right is already there, and I was successfully able to queue the apc.
In fact when we use OpenThread (…) we can specify the access rights that we need (from those that are available).
> DuplicateHandle is a must.
I realized this too. Earlier what I was doing was, sending the handle directly from process A to B and was using that handle in process B. The correct approach was to send thread_id, and use it to open the handle and then use the handle.
Why does a handle become invalid in context of other process?
—
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
> Why does a handle become invalid in context of other process?
Because the kernel has a personal handle table for each process.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com