Modifying ACL on already loaded device
in [Device Drivers]
|
From: Mark on 11 Feb 2010 04:29 I wondered if there was a way of changing/adding the ACL on already loaded device (eg COM1, LPT1, Bluetooth). I know that if i'm writing my own driver I can specify an ACL on my device via IoCreateDeviceIO, in my driver's .inf file or even via SetupDiSetDeviceRegistryProperty but, as I understand it, these only set up the ACL when the driver is loaded. However, I want to do this 'on the fly' (ie. after the driver has been loaded and to be effective immediately) and for devices controlled by standard microsoft supplied drivers. I wondered if SetKernelObjectSecurity might be the way to go ? Any information or hints would be a great help. Mark
From: Scott Noone on 11 Feb 2010 07:06 >I wondered if SetKernelObjectSecurity might be the way to go ? Yup, that will do it from user mode (it's how we do it in our Object Viewer application). Assuming that you can get a handle to the object, of course. -scott -- Scott Noone Consulting Associate OSR Open Systems Resources, Inc. http://www.osronline.com "Mark" <markwood666(a)googlemail.com> wrote in message news:c2f08f05-b3c9-4de8-b965-285aabcdb6e3(a)a32g2000yqm.googlegroups.com... > I wondered if there was a way of changing/adding the ACL on already > loaded device (eg COM1, LPT1, Bluetooth). I know that if i'm writing > my own driver I can specify an ACL on my device via IoCreateDeviceIO, > in my driver's .inf file or even via SetupDiSetDeviceRegistryProperty > but, as I understand it, these only set up the ACL when the driver is > loaded. > > However, I want to do this 'on the fly' (ie. after the driver has > been loaded and to be effective immediately) and for devices > controlled by standard microsoft supplied drivers. I wondered if > SetKernelObjectSecurity might be the way to go ? > > Any information or hints would be a great help. > > Mark
From: Maxim S. Shatskih on 11 Feb 2010 07:15 > >I wondered if SetKernelObjectSecurity might be the way to go ? > > Yup, that will do it from user mode (it's how we do it in our Object Viewer > application). Assuming that you can get a handle to the object, of course. SetNamedSecurityInfo for a file with a proper pathname (to open the device itself and not the file on it) will also suite. -- Maxim S. Shatskih Windows DDK MVP maxim(a)storagecraft.com http://www.storagecraft.com
From: Mark on 11 Feb 2010 12:27 thanks for that .... a few other questions that have occurred to me .. - will this work for non-plug and play devices ? - Also, I assume my ACL should be on the device objects created by the driver rather than the driver object itself ?? - Should i put my ACL on all devices in the device stack to be safe ? - Does the system actually enforce the checking of the ACL and the granting/denying of access or am i relying on the driver doing it thanks, Mark
From: Maxim S. Shatskih on 11 Feb 2010 12:57 > - will this work for non-plug and play devices ? Yes. > - Also, I assume my ACL should be on the device objects created by the > driver rather than the driver object itself ?? On device object. > - Should i put my ACL on all devices in the device stack to be safe ? No, only on named ones. > - Does the system actually enforce the checking of the ACL Yes it does. But note that in a devnode, the actually opened by name DO is the one used for checks - the actual bearer of the name. That's why MS suggests all DOs in the devnode to be nameless except the PDO with the autogenerated name and the symlinks referencing this name. Sometimes this is violated. On a CD/DVD stack, the PnP device interface name references the PDO created by the storage port, while \\.\E: reference the FDO created by CdRom.sys. They have different ACLs. -- Maxim S. Shatskih Windows DDK MVP maxim(a)storagecraft.com http://www.storagecraft.com
|
Next
|
Last
Pages: 1 2 Prev: Do WIA scan without calling IWiaDevMgr->DeviceDlg() Next: General portio sample problem |