User Access Control with Virtual COM Ports

NTDEV
1

I am currently working on a WDF driver for a USB Virtual COM port device. The driver itself is working well and is passing all of my data integrity and COM API testing as well as the DTMs.

When I run my test applications however, they need to be run in elevated mode (right click and Run As Administrator) or the CreateFile on the virtual COM port will return a 5, Access Denied.

There is an existing driver that can currently be used with the USB device that doesn’t require the elevation and is written using WDM instead. I don’t have access to that source however.

Is there a way in the INF or at device creation process that will eliminate the need to “run as an administrator” when accessing the virtual port, or is this something that is just inherent? It seems like there is some way around it since I have an existing driver that doesn’t require it, but could this be due to the WDM/WDF differences? Any info on this would help; I am OK with this as most of Vista contains these quirks, but customers will probably not feel the same.

2

I believe the problem is that WDF, by default, restricts access to a
named device object to the system and admins accounts only; on the other
hand, the device object of a normal serial driver is supposed to be open
to normal user. You can override this by calling
WdfDeviceInitAssignSDDLString() in your EvtDriverDeviceAdd(), with an
SDDL string such as “D:P(A;;GRGW;;;WD)(A;;GR;;;RC)(A;;GA;;;SY)(A;;GA;;;BA)”.

xxxxx@silabs.com wrote:

I am currently working on a WDF driver for a USB Virtual COM port device. The driver itself is working well and is passing all of my data integrity and COM API testing as well as the DTMs.

When I run my test applications however, they need to be run in elevated mode (right click and Run As Administrator) or the CreateFile on the virtual COM port will return a 5, Access Denied.

There is an existing driver that can currently be used with the USB device that doesn’t require the elevation and is written using WDM instead. I don’t have access to that source however.

Is there a way in the INF or at device creation process that will eliminate the need to “run as an administrator” when accessing the virtual port, or is this something that is just inherent? It seems like there is some way around it since I have an existing driver that doesn’t require it, but could this be due to the WDM/WDF differences? Any info on this would help; I am OK with this as most of Vista contains these quirks, but customers will probably not feel the same.

Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

3

“Faris Y. Yau” wrote in message news:xxxxx@ntdev…
>I believe the problem is that WDF, by default, restricts access to a named
>device object to the system and admins accounts only; on the other hand,
>the device object of a normal serial driver is supposed to be open to
>normal user. You can override this by calling
>WdfDeviceInitAssignSDDLString() in your EvtDriverDeviceAdd(), with an SDDL
>string such as “D:P(A;;GRGW;;;WD)(A;;GR;;;RC)(A;;GA;;;SY)(A;;GA;;;BA)”.
>
Sorry, this has nothing to do with WDF. Vista changed things, I know it
has been disscussed on this group or NTDEV, but bottom line, is Microsoft
made it much so only system account can manipulate ENUM in Vista.

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply

4

My typo, should have said NTDEV or
microsoft.public.development.device.drivers.

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply

“Don Burn” wrote in message news:xxxxx@ntdev…
>
> “Faris Y. Yau” wrote in message news:xxxxx@ntdev…
>>I believe the problem is that WDF, by default, restricts access to a
>>named device object to the system and admins accounts only; on the other
>>hand, the device object of a normal serial driver is supposed to be open
>>to normal user. You can override this by calling
>>WdfDeviceInitAssignSDDLString() in your EvtDriverDeviceAdd(), with an
>>SDDL string such as
>>“D:P(A;;GRGW;;;WD)(A;;GR;;;RC)(A;;GA;;;SY)(A;;GA;;;BA)”.
>>
> Sorry, this has nothing to do with WDF. Vista changed things, I know it
> has been disscussed on this group or NTDEV, but bottom line, is Microsoft
> made it much so only system account can manipulate ENUM in Vista.
>
>
> –
> Don Burn (MVP, Windows DDK)
> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> Website: http://www.windrvr.com
> Blog: http://msmvps.com/blogs/WinDrvr
> Remove StopSpam to reply
>
>

5

You can use the INF which installs the com port driver to specify the
ACL you want. See the “INF AddReg Directive” section in the WDK,
specifically the Security value:


Security
A Security entry specifies a security descriptor for the device. The
security-descriptor-string is a string with tokens to indicate the DACL
(D:) security component. See Platform SDK documentation for information
about the format of security descriptor strings. A class-installer INF
can specify a security descriptor for a device class. A device INF can
specify a security descriptor for an individual device, overriding the
security for the class. If the class and/or device INF specifies a
security-descriptor-string, the PnP manager propagates the descriptor to
all the device objects for a device, including the FDO, filter DOs, and
the PDO.

Any current access checks are inherit in the OS, not KMDF. We don’t do
anything other then call IoCreateDevice. Before you try the INF
directive (which would require a reinstall), are you giving your FDO an
explicit name? perhaps try an anon FDO and see if that changes anything

d
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@silabs.com
Sent: Wednesday, June 20, 2007 3:51 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] User Access Control with Virtual COM Ports

I am currently working on a WDF driver for a USB Virtual COM port
device. The driver itself is working well and is passing all of my data
integrity and COM API testing as well as the DTMs.

When I run my test applications however, they need to be run in elevated
mode (right click and Run As Administrator) or the CreateFile on the
virtual COM port will return a 5, Access Denied.

There is an existing driver that can currently be used with the USB
device that doesn’t require the elevation and is written using WDM
instead. I don’t have access to that source however.

Is there a way in the INF or at device creation process that will
eliminate the need to “run as an administrator” when accessing the
virtual port, or is this something that is just inherent? It seems like
there is some way around it since I have an existing driver that doesn’t
require it, but could this be due to the WDM/WDF differences? Any info
on this would help; I am OK with this as most of Vista contains these
quirks, but customers will probably not feel the same.

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

6

OR, the much easier case is to just not give your device a name. You
can still create a symbolic link against the FDO (we use the PDO name)
or a PDO as well as device interfaces. The actual device name is not
important for a COM port, just the symbolic link name is important.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Faris Y. Yau
Sent: Wednesday, June 20, 2007 4:03 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] User Access Control with Virtual COM Ports

I believe the problem is that WDF, by default, restricts access to a
named device object to the system and admins accounts only; on the other

hand, the device object of a normal serial driver is supposed to be open

to normal user. You can override this by calling
WdfDeviceInitAssignSDDLString() in your EvtDriverDeviceAdd(), with an
SDDL string such as
“D:P(A;;GRGW;;;WD)(A;;GR;;;RC)(A;;GA;;;SY)(A;;GA;;;BA)”.

xxxxx@silabs.com wrote:

I am currently working on a WDF driver for a USB Virtual COM port
device. The driver itself is working well and is passing all of my data
integrity and COM API testing as well as the DTMs.

When I run my test applications however, they need to be run in
elevated mode (right click and Run As Administrator) or the CreateFile
on the virtual COM port will return a 5, Access Denied.

There is an existing driver that can currently be used with the USB
device that doesn’t require the elevation and is written using WDM
instead. I don’t have access to that source however.

Is there a way in the INF or at device creation process that will
eliminate the need to “run as an administrator” when accessing the
virtual port, or is this something that is just inherent? It seems like
there is some way around it since I have an existing driver that doesn’t
require it, but could this be due to the WDM/WDF differences? Any info
on this would help; I am OK with this as most of Vista contains these
quirks, but customers will probably not feel the same.

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

7

Actually don, Faris is correct. If you create an explicitly named
devobj in KMDF, we give you a default SDDL of
SDDL_DEVOBJ_SYS_ALL_ADM_ALL (see wdfsec.h for the full SDDL string).
This behavior is documented in the WDK, under the topic “Controlling
Device Access in Framework-Based Drivers” which is also linked from the
help topic for WdfDeviceInitAssignName

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Wednesday, June 20, 2007 4:06 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] User Access Control with Virtual COM Ports

“Faris Y. Yau” wrote in message news:xxxxx@ntdev…
>I believe the problem is that WDF, by default, restricts access to a
named
>device object to the system and admins accounts only; on the other
hand,
>the device object of a normal serial driver is supposed to be open to
>normal user. You can override this by calling
>WdfDeviceInitAssignSDDLString() in your EvtDriverDeviceAdd(), with an
SDDL
>string such as “D:P(A;;GRGW;;;WD)(A;;GR;;;RC)(A;;GA;;;SY)(A;;GA;;;BA)”.
>
Sorry, this has nothing to do with WDF. Vista changed things, I know it

has been disscussed on this group or NTDEV, but bottom line, is
Microsoft
made it much so only system account can manipulate ENUM in Vista.

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

8

Thanks for the reply Faris and Doron - that was exactly what I thought was happening. I was indeed giving the device a name, so I just included the WdfDeviceInitAssignSDDLString() after that call to assign it the desired security settings.

Thanks again, and apologies for bringing up the UAC issue - but hopefully the solution here will help someone else out later.