1
votes

I'm running Windows 7 on a Kontron evaluation board, and I'm having problems talking to one of their drivers without running my application with elevated privileges as an administrator. The driver allows us to read from and write to the GPIO pins on the board. There is one driver that is installed and a couple DLL's in the system32 directory that expose the API we are using to talk to the driver. When I run my test application without elevated privileges, the API call to initialize the board fails. When I run my test application with elevated privileges, the API call passes. The test applications that came with the Kontron driver install all prompt to run with elevated privileges before running, but I don't understand why elevated privileges are needed.

I've been searching Google all morning trying to find a reason for this, but I can't find any information, or I'm not searching for the right terms. I just want to determine whether or not I will be able to get around having to run with elevated privileges or if that's just the way it is. So does Windows 7 have restrictions on talking to drivers that access the hardware directly? Does it have to do with the location of the DLL files? Does it have to do with the way they install the driver? Does it have to do with the way they built their DLL's?

Any information explaining why I'm experiencing this would be great.

1
If the samples from the vendor show that admin privileges are required, then they're apparently required, and you should ask the vendor why that is the case. Voting to close as "off topic"; this is a vendor support question and not a StackOverflow one, IMO.Ken White
I gave the specifics to give some context. The question is more generally asking if there are certain restrictions on Windows 7 for talking to drivers without elevated privileges.EarlCrapstone
The access control list for a device object is determined by the device driver, either at runtime or during installation.Harry Johnston
Thanks for pointing me in the right direction, Harry. I looked into ACLs, and answered my own question with some links.EarlCrapstone
Only your vendor can answer the question "Why does this vendor DLL require elevation?" It may be because of ACLs on the driver, or it may be because the DLL does something else that requires admin privileges. Only the vendor will know for sure.Raymond Chen

1 Answers

0
votes

Per Harry's comment, I looked into Windows Access Control Lists (ACLs). The device driver is responsible for setting up the access rights for the device object. In my case, it appears that the driver is setting them at runtime because there are not any security settings specified in the driver's INF file.

Here are some links with more information:

Of SDs, ACLs & INFs: The INs and OUTs of Device Object Protection

SuperUser: What are Windows ACLs?

MSDN: Access Control

MSDN: Applying Security Descriptors on the Device Object

SysInternals: WinObj tool