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

>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@googlemail.com> wrote in message 
news:c2f08f05-b3c9-4de8-b965-285aabcdb6e3@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 

> >I wondered if SetKernelObjectSecurity might be the way to go ?
>=20
> Yup, that will do it from user mode (it's how we do it in our Object =
Viewer=20
> 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.

--=20
Maxim S. Shatskih
Windows DDK MVP
maxim@storagecraft.com
http://www.storagecraft.com

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

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

--=20
Maxim S. Shatskih
Windows DDK MVP
maxim@storagecraft.com
http://www.storagecraft.com

On 11 Feb, 17:57, "Maxim S. Shatskih" <ma...@storagecraft.com.no.spam>
wrote:
> > - 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 =A0??
>
> 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 i=
s 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 P=
DO with the autogenerated name and the symlinks referencing this name.
>
> Sometimes this is violated. On a CD/DVD stack, the PnP device interface n=
ame 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
> ma...@storagecraft.comhttp://www.storagecraft.com

Many thanks Maxim ... greatly appreciate the help.