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.
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