Easiest solution when using the SysInternals approach: save the pointer
to the original descriptor, and point the device object to your new
descriptor. When it comes time to delete your device object, free your
descriptor, then point the device object back to the original
descriptor, and then delete the device.
- Nicholas Ryan
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Michal Vodicka
Sent: Monday, March 03, 2003 10:35 AM
To: NT Developers Interest List
Subject: [ntdev] RE: Device driver object security settings
to enable non-priv’d user accessIt seems there is a problem with this approach at XP. Last
week I encountered something similar with VMware parallel
driver which access caused random data overwrite. It seemed
as the problem caused my driver I’m working on so I
investigated the problem and found OS tried to access data
before security descriptor for this driver device. The
descriptor was created the way you describe; they create new
one and change
DeviceObject->SecurityDescriptor to its address. They don’t
free the old
DeviceObject->one
and I presume it is because it caused the same problem as you have.I guess device security descriptor at XP are objects and OS
expects object header prepended to memory pointed with
DeviceObject->SecurityDescriptor. It would explain why
ExFreePool fails: the real allocation starts several bytes
before. Please note I only guess; I’d appreciate if somebody
can confirm or disprove this observation or give any more
info about XP device SDs.Also please note above described approach (ignore problem and
don’t free original descriptor) is plain wrong and can cause
BSODs or worse, random data overwrite. You can try different
approach: change original SD contents instead. It is usable
way if all you need is to change an ACE mask. I used it at
w2k with no problem.Best regards,
Michal Vodicka
STMicroelectronics Design and Application s.r.o.
[michal.vodicka@st.com, http:://www.st.com]> ----------
> From: Barry.Kierstein@HP.Com[SMTP:Barry.Kierstein@HP.Com]
> Reply To: xxxxx@lists.osr.com
> Sent: Monday, March 03, 2003 6:42 PM
> To: xxxxx@lists.osr.com
> Subject: [ntdev] RE: Device driver object security
settings to enable
> non-priv’d user access
>
> All,
>
> Thanks for your great suggestions. I have followed the
> SysInternals example in modifying the security descriptor in the
> device object. There is one remaining oddity.
>
> Basically, the SysInternals example does the following:
> 1) gets the security descriptor from the device object
> (it is in relative format),
> 2) creates an empty absolute format security descriptor,
> 3) reads the device object security descriptor for various
attributes
> and sets these in the absolute security descriptor,
> 4) converts the absolute security descriptor to relative
format security
> descriptor,
> 5) frees the device object’s security descriptor using
ExFreePool, and
> 6) sets the device object’s security descriptor pointer to the new
> relative format security descriptor.
>
> This works fine on Windows 2000. On Windows XP, it
bugchecks when
> trying to execute the ExFreePool call with a stop code of 0xC2.
>
> BAD_POOL_CALLER (c2)
> The current thread is making a bad pool request.
> Typically this is at a bad IRQL level or double freeing the same
> allocation, etc.
> Arguments:
> Arg1: 00000007, Attempt to free pool which was already freed
> Arg2: 00000cd4, (reserved)
> Arg3: 00000027, Memory contents of the pool block
> Arg4: e13f5318, Pointer to pool header
>
> Any ideas why this is happening? Thanks…
>
> Barry Kierstein
>
> —
> You are currently subscribed to ntdev as: michal.vodicka@st.com To
> unsubscribe send a blank email to xxxxx@lists.osr.com
>
You are currently subscribed to ntdev as: xxxxx@nryan.com
To unsubscribe send a blank email to xxxxx@lists.osr.com