I saw this on a closed thread:
"
ntdev member 37569
I want to share events between my console application and a UMDF driver.
If I create the events in the application and then try to open them in
the UMDF driver I get
Error message 02 - Error_File_Not_Found.
Is there any way I can do this. I have tried passing the event Handles
to OnDeviceIOControl
but still am unable to ‘open’ and ‘set’ the events.
I did not saw any answer to this “trivial” question
Since I have the answer I want to post it here…
" SECURITY_DESCRIPTOR SecDescriptor;
SECURITY_ATTRIBUTES SecAttributes;
InitializeSecurityDescriptor(&SecDescriptor,SECURITY_DESCRIPTOR_REVISION);
SetSecurityDescriptorDacl(&SecDescriptor,TRUE,NULL,FALSE);
SecAttributes.nLength = sizeof(SECURITY_ATTRIBUTES);
SecAttributes.lpSecurityDescriptor = &SecDescriptor;
SecAttributes.bInheritHandle = TRUE;
m_hMutex = CreateMutexW(
&SecAttributes, // default security attributes
FALSE, // initially not owned
L"{Yor Muttex Name}");
"
This definitely not my thing, but as a place to start, have you tried creating the mutex in the
global namespace (“Global\{Yor Muttex Name}”)? I don’t know in what session the UMDF host runs or
under what account, nor on what version of the os that you are running, but this is an easy thing to
try, at least.
Good luck,
mm
xxxxx@hotmail.com wrote:
I saw this on a closed thread:
"
ntdev member 37569
I want to share events between my console application and a UMDF driver.
If I create the events in the application and then try to open them in
the UMDF driver I get
Error message 02 - Error_File_Not_Found.
Is there any way I can do this. I have tried passing the event Handles
to OnDeviceIOControl
but still am unable to ‘open’ and ‘set’ the events.
I did not saw any answer to this “trivial” question
Since I have the answer I want to post it here…
" SECURITY_DESCRIPTOR SecDescriptor;
SECURITY_ATTRIBUTES SecAttributes;
InitializeSecurityDescriptor(&SecDescriptor,SECURITY_DESCRIPTOR_REVISION);
SetSecurityDescriptorDacl(&SecDescriptor,TRUE,NULL,FALSE);
SecAttributes.nLength = sizeof(SECURITY_ATTRIBUTES);
SecAttributes.lpSecurityDescriptor = &SecDescriptor;
SecAttributes.bInheritHandle = TRUE;
m_hMutex = CreateMutexW(
&SecAttributes, // default security attributes
FALSE, // initially not owned
L"{Yor Muttex Name}");
"
My bad; I just found this thread in Thunderbird (which is a pain in the ass, by the way), and it
seems we’ve been there, done that.
mm
Martin O’Brien wrote:
This definitely not my thing, but as a place to start, have you tried
creating the mutex in the global namespace (“Global\{Yor Muttex
Name}”)? I don’t know in what session the UMDF host runs or under what
account, nor on what version of the os that you are running, but this is
an easy thing to try, at least.
Good luck,
mm
xxxxx@hotmail.com wrote:
> I saw this on a closed thread:
> "
> ntdev member 37569
>
> I want to share events between my console application and a UMDF driver.
>
>
>
> If I create the events in the application and then try to open them in
> the UMDF driver I get
>
> Error message 02 - Error_File_Not_Found.
>
>
>
> Is there any way I can do this. I have tried passing the event Handles
> to OnDeviceIOControl
>
> but still am unable to ‘open’ and ‘set’ the events.
>
> I did not saw any answer to this “trivial” question
>
> Since I have the answer I want to post it here…
>
> " SECURITY_DESCRIPTOR SecDescriptor;
> SECURITY_ATTRIBUTES SecAttributes;
>
> InitializeSecurityDescriptor(&SecDescriptor,SECURITY_DESCRIPTOR_REVISION);
>
> SetSecurityDescriptorDacl(&SecDescriptor,TRUE,NULL,FALSE);
>
> SecAttributes.nLength = sizeof(SECURITY_ATTRIBUTES);
> SecAttributes.lpSecurityDescriptor = &SecDescriptor;
> SecAttributes.bInheritHandle = TRUE;
>
> m_hMutex = CreateMutexW(
> &SecAttributes, // default security attributes
> FALSE, // initially not owned
> L"{Yor Muttex Name}");
> "
The reasons for event not accessible to UMDF driver are:
-
Unlike a topmost KM driver, UMDF driver runs in a different process context w.r.t. to the application so the handle passed is meaningless for UMDF driver. That is why you need the event to be discoverable by making it a named event.
-
UMDF driver runs under Local Service account which is likely different from the account application runs under, which is why it doesn’t have access to the event, by default.
Instead of using NULL dacl as described below (which just removes all protection on the event):
- You can add Local Service access to the dacl of the event application creates - if it is OK to open up the event to Local Service accounts.
- Or, use impersonation in UMDF driver to access the event - if you want to retain all the security on the event and have only UMDF driver access it. Please check out IWDFIoRequest::Impersonate and “impersonation” version of fx2 sample for impersonation usage.
HTH,
Praveen
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Martin O’Brien
Sent: Monday, March 16, 2009 10:01 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Event betweens a console application and a UMDF driver ?
My bad; I just found this thread in Thunderbird (which is a pain in the ass, by the way), and it
seems we’ve been there, done that.
mm
Martin O’Brien wrote:
This definitely not my thing, but as a place to start, have you tried
creating the mutex in the global namespace (“Global\{Yor Muttex
Name}”)? I don’t know in what session the UMDF host runs or under what
account, nor on what version of the os that you are running, but this is
an easy thing to try, at least.
Good luck,
mm
xxxxx@hotmail.com wrote:
> I saw this on a closed thread:
> "
> ntdev member 37569
>
> I want to share events between my console application and a UMDF driver.
>
>
>
> If I create the events in the application and then try to open them in
> the UMDF driver I get
>
> Error message 02 - Error_File_Not_Found.
>
>
>
> Is there any way I can do this. I have tried passing the event Handles
> to OnDeviceIOControl
>
> but still am unable to ‘open’ and ‘set’ the events.
>
> I did not saw any answer to this “trivial” question
>
> Since I have the answer I want to post it here…
>
> " SECURITY_DESCRIPTOR SecDescriptor;
> SECURITY_ATTRIBUTES SecAttributes;
>
> InitializeSecurityDescriptor(&SecDescriptor,SECURITY_DESCRIPTOR_REVISION);
>
> SetSecurityDescriptorDacl(&SecDescriptor,TRUE,NULL,FALSE);
>
> SecAttributes.nLength = sizeof(SECURITY_ATTRIBUTES);
> SecAttributes.lpSecurityDescriptor = &SecDescriptor;
> SecAttributes.bInheritHandle = TRUE;
>
> m_hMutex = CreateMutexW(
> &SecAttributes, // default security attributes
> FALSE, // initially not owned
> L"{Yor Muttex Name}");
> "
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
Said (2) backwards - should be ERROR_ACCESS_DENIED not ERROR_FILE_NOT_FOUND.
Martin O’Brien wrote:
Praveen:
-
I missed this part and had assumed that he was trying to open the
named event, so I see what
you’re saying here.
-
This is also what I had in mind, but I don’t understand why the dev
(or the previous one) would
receive an ERROR_FILE_NOT_FOUND and not ERROR_ACCESS_DENIED? If he’s
getting ERROR_FILE_NOT_FOUND,
assuming the dev’s doing things correctly (which we don’t know, as the
dev hasn’t posted that part
of the code), this wouldn’t seem to be the dev’s immediate problem, and
wouldn’t using NULL permit access, just not granularly?
-
This is what made me wonder about the Global\Local issue; I know
that saw that the earlier posts in this thread indicate that it’s not
the problem either, but I’m not sure what else there is that could be
doing this, assuming that the dev is running on Vista+ (which we also
don’t know).
Thanks,
mm
Praveen Rao wrote:
> The reasons for event not accessible to UMDF driver are:
>
> 1) Unlike a topmost KM driver, UMDF driver runs in a different process
> context w.r.t. to the application so the handle passed is meaningless
> for UMDF driver. That is why you need the event to be discoverable by
> making it a named event.
>
> 2) UMDF driver runs under Local Service account which is likely
> different from the account application runs under, which is why it
> doesn’t have access to the event, by default.
>
> Instead of using NULL dacl as described below (which just removes all
> protection on the event):
> 1) You can add Local Service access to the dacl of the event
> application creates - if it is OK to open up the event to Local
> Service accounts.
> 2) Or, use impersonation in UMDF driver to access the event - if you
> want to retain all the security on the event and have only UMDF driver
> access it. Please check out IWDFIoRequest::Impersonate and
> “impersonation” version of fx2 sample for impersonation usage.
>
> HTH,
> Praveen
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Martin O’Brien
> Sent: Monday, March 16, 2009 10:01 AM
> To: Windows System Software Devs Interest List
> Subject: Re:[ntdev] Event betweens a console application and a UMDF
> driver ?
>
> My bad; I just found this thread in Thunderbird (which is a pain in
> the ass, by the way), and it
> seems we’ve been there, done that.
>
> mm
>
> Martin O’Brien wrote:
>> This definitely not my thing, but as a place to start, have you tried
>> creating the mutex in the global namespace (“Global\{Yor Muttex
>> Name}”)? I don’t know in what session the UMDF host runs or under what
>> account, nor on what version of the os that you are running, but this is
>> an easy thing to try, at least.
>>
>>
>> Good luck,
>>
>> mm
>>
>>
>>
>> xxxxx@hotmail.com wrote:
>>> I saw this on a closed thread:
>>> "
>>> ntdev member 37569
>>>
>>> I want to share events between my console application and a UMDF
>>> driver.
>>>
>>>
>>>
>>> If I create the events in the application and then try to open them in
>>> the UMDF driver I get
>>>
>>> Error message 02 - Error_File_Not_Found.
>>>
>>>
>>>
>>> Is there any way I can do this. I have tried passing the event Handles
>>> to OnDeviceIOControl
>>>
>>> but still am unable to ‘open’ and ‘set’ the events.
>>>
>>> I did not saw any answer to this “trivial” question
>>>
>>> Since I have the answer I want to post it here…
>>>
>>> " SECURITY_DESCRIPTOR SecDescriptor;
>>> SECURITY_ATTRIBUTES SecAttributes;
>>>
>>>
>>> InitializeSecurityDescriptor(&SecDescriptor,SECURITY_DESCRIPTOR_REVISION);
>>>
>>>
>>> SetSecurityDescriptorDacl(&SecDescriptor,TRUE,NULL,FALSE);
>>>
>>> SecAttributes.nLength = sizeof(SECURITY_ATTRIBUTES);
>>> SecAttributes.lpSecurityDescriptor = &SecDescriptor;
>>> SecAttributes.bInheritHandle = TRUE;
>>>
>>> m_hMutex = CreateMutexW(
>>> &SecAttributes, // default security attributes
>>> FALSE, // initially not owned
>>> L"{Yor Muttex Name}");
>>> "
>
> —
> 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
>
>
> Said (2) backwards - should be ERROR_ACCESS_DENIED not ERROR_FILE_NOT_FOUND.
True. I was just summarizing the whole issue and mentioned #1 and #2 as the causes of not being able to use the event in UMDF driver.
ERROR_FILE_NOT_FOUND is likely because of #1 (someone just passing event handle to UMDF driver). That would be alleviated with a named event. Next stumble would be on ERROR_ACCESS_DENIED for which impersonation can be used, LS access can be added to the event or - as the least preferred method - NULL dacl can be used for the event.
Praveen
ps: To me it seemed like “xxxxx@hotmail.com” posted the solution he/she found and not a question. From the post (“Since I have the answer I want to post it here…”). I just wanted to clarify that NULL dacl isn’t the only way - and in fact should be the last thing to use.
Thanks, Praveen.
I’m still not really sure what the dev has or has not tried.
mm
Praveen Rao wrote:
> Said (2) backwards - should be ERROR_ACCESS_DENIED not ERROR_FILE_NOT_FOUND.
True. I was just summarizing the whole issue and mentioned #1 and #2 as the causes of not being able to use the event in UMDF driver.
ERROR_FILE_NOT_FOUND is likely because of #1 (someone just passing event handle to UMDF driver). That would be alleviated with a named event. Next stumble would be on ERROR_ACCESS_DENIED for which impersonation can be used, LS access can be added to the event or - as the least preferred method - NULL dacl can be used for the event.
Praveen
ps: To me it seemed like “xxxxx@hotmail.com” posted the solution he/she found and not a question. From the post (“Since I have the answer I want to post it here…”). I just wanted to clarify that NULL dacl isn’t the only way - and in fact should be the last thing to use.
> I’m still not really sure what the dev has or has not tried.
Not using NULL dacl on the event.
Again, I didn’t think that the dev had any outstanding question. As I read it, the dev had it working but with a NULL dacl solution. If that is not the case I would request the dev to please let us know.
Thanks,
Praveen