File sharing access

OSR_Community_User · December 3, 2007, 10:33am

Hi,
could someone tell me how I can grand access to specific user32 application.
The idea is that this application should be able to write into a file that is opened by another application with exclusive access (just the way my filter driver is able to). I tried some stuff:

Creating a handle with OBJ_KERNEL_HANDLE flag in the driver and pass it to the user32 app
but (not surprisingly at all ) the application threw invalid handle exception.
I tried to forcibly change the requested access from other application to a file, so that no one could open it exclusively:

Data->Iopb->Parameters.Create.ShareAccess |= FILE_SHARE_WRITE;
Data->Iopb->Parameters.Create.ShareAccess |= FILE_SHARE_READ;

and still no success
3. I tried to change the request mode of the user32 app
if ( hCurrentProcessID == ProcessIDs[1] )
{
Data->RequestorMode = (KPROCESSOR_MODE)KernelMode;
}
(a long shot and really desperate attempt)

It is more then obvious that the i/o manager and the filter manager do some kind of validation and forbid such actions!
Any ideas on how I could managed to do that? The code that I use to lock the file for testing is:

FileStream fs = File.Open(FileName,FileMode.Open,FileAccess.ReadWrite,FileShare.None);

Eric_Diven · December 3, 2007, 11:08am

Stupid question, but when you try to add read/write share in approach 2,
do you remember to call FltSetCallbackDataDirty()? I only ask because
I’ve seen doing just that work. This is Q7 on the FAQ, by the way,
which suggests memory mapping the file in the filter driver as an
alternative to taking over the sharing semantics. I’ve got a similar
problem on my plate, and the jury is still out for me as to which
approach I’m going to take.

~Eric

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@abv.bg
Sent: Monday, December 03, 2007 10:34 AM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] File sharing access

Hi,
could someone tell me how I can grand access to specific user32
application.
The idea is that this application should be able to write into a file
that is opened by another application with exclusive access (just the
way my filter driver is able to). I tried some stuff:

Creating a handle with OBJ_KERNEL_HANDLE flag in the driver and pass
it to the user32 app but (not surprisingly at all ) the application
threw invalid handle exception.
I tried to forcibly change the requested access from other
application to a file, so that no one could open it exclusively:

Data->Iopb->Parameters.Create.ShareAccess |= FILE_SHARE_WRITE;
Data->Iopb->Parameters.Create.ShareAccess |= FILE_SHARE_READ;

and still no success
3. I tried to change the request mode of the user32 app
if ( hCurrentProcessID == ProcessIDs[1] )
{
Data->RequestorMode = (KPROCESSOR_MODE)KernelMode;
}
(a long shot and really desperate attempt)

It is more then obvious that the i/o manager and the filter manager
do some kind of validation and forbid such actions!
Any ideas on how I could managed to do that? The code that I use to
lock the file for testing is:

FileStream fs =
File.Open(FileName,FileMode.Open,FileAccess.ReadWrite,FileShare.None);

NTFSD is sponsored by OSR

For our schedule debugging and file system seminars (including our new
fs mini-filter seminar) visit:
http://www.osr.com/seminars

You are currently subscribed to ntfsd as: xxxxx@edsiohio.com To
unsubscribe send a blank email to xxxxx@lists.osr.com

Don_Burn_1 · December 3, 2007, 11:15am

The memory mapping stuff is more for byte range locks, not share modes. The
whole problem can be done without a file system filter at all. I have in
the past created a driver that an application can perform a create on with
actual pathname appended to the driver path. The create code in the driver,
then opens the real file with IoCreateFileSpecifyDeviceObjectHint overriding
the share checks. On read and writes the driver just performs the file io
(or if you want to be fancy does it mapped to bypass the byte range
locking).

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply

“Eric Diven” wrote in message news:xxxxx@ntfsd…
Stupid question, but when you try to add read/write share in approach 2,
do you remember to call FltSetCallbackDataDirty()? I only ask because
I’ve seen doing just that work. This is Q7 on the FAQ, by the way,
which suggests memory mapping the file in the filter driver as an
alternative to taking over the sharing semantics. I’ve got a similar
problem on my plate, and the jury is still out for me as to which
approach I’m going to take.

~Eric

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@abv.bg
Sent: Monday, December 03, 2007 10:34 AM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] File sharing access

Hi,
could someone tell me how I can grand access to specific user32
application.
The idea is that this application should be able to write into a file
that is opened by another application with exclusive access (just the
way my filter driver is able to). I tried some stuff:
1. Creating a handle with OBJ_KERNEL_HANDLE flag in the driver and pass
it to the user32 app but (not surprisingly at all ) the application
threw invalid handle exception.
2. I tried to forcibly change the requested access from other
application to a file, so that no one could open it exclusively:

Data->Iopb->Parameters.Create.ShareAccess |= FILE_SHARE_WRITE;
Data->Iopb->Parameters.Create.ShareAccess |= FILE_SHARE_READ;

and still no success
3. I tried to change the request mode of the user32 app
if ( hCurrentProcessID == ProcessIDs[1] )
{
Data->RequestorMode = (KPROCESSOR_MODE)KernelMode;
}
(a long shot and really desperate attempt)

It is more then obvious that the i/o manager and the filter manager
do some kind of validation and forbid such actions!
Any ideas on how I could managed to do that? The code that I use to
lock the file for testing is:

FileStream fs =
File.Open(FileName,FileMode.Open,FileAccess.ReadWrite,FileShare.None);

—
NTFSD is sponsored by OSR

For our schedule debugging and file system seminars (including our new
fs mini-filter seminar) visit:
http://www.osr.com/seminars

You are currently subscribed to ntfsd as: xxxxx@edsiohio.com To
unsubscribe send a blank email to xxxxx@lists.osr.com

Eric_Diven · December 3, 2007, 11:43am

I’m a little fuzzy on how this avoids the sharing access issue. If the
request originates in the kernel, the share access checks are still
made, right? The MSDN suggests that the use of
IO_IGNORE_SHARE_ACCESS_CHECK may not work, because the FS may still
perform the checks itself. Am I incorrect in my understanding about the
share access checks, or is it the case that the FS always does honor the
IO_IGNORE_SHARE_ACCESS_CHECK option?

~Eric

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Monday, December 03, 2007 11:15 AM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] File sharing access

The memory mapping stuff is more for byte range locks, not share modes.
The whole problem can be done without a file system filter at all. I
have in the past created a driver that an application can perform a
create on with actual pathname appended to the driver path. The create
code in the driver, then opens the real file with
IoCreateFileSpecifyDeviceObjectHint overriding
the share checks. On read and writes the driver just performs the file
io
(or if you want to be fancy does it mapped to bypass the byte range
locking).

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply

“Eric Diven” wrote in message
news:xxxxx@ntfsd…
Stupid question, but when you try to add read/write share in approach 2,
do you remember to call FltSetCallbackDataDirty()? I only ask because
I’ve seen doing just that work. This is Q7 on the FAQ, by the way,
which suggests memory mapping the file in the filter driver as an
alternative to taking over the sharing semantics. I’ve got a similar
problem on my plate, and the jury is still out for me as to which
approach I’m going to take.

~Eric

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@abv.bg
Sent: Monday, December 03, 2007 10:34 AM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] File sharing access

Hi,
could someone tell me how I can grand access to specific user32
application.
The idea is that this application should be able to write into a file
that is opened by another application with exclusive access (just the
way my filter driver is able to). I tried some stuff:
1. Creating a handle with OBJ_KERNEL_HANDLE flag in the driver and pass
it to the user32 app but (not surprisingly at all ) the application
threw invalid handle exception.
2. I tried to forcibly change the requested access from other
application to a file, so that no one could open it exclusively:

Data->Iopb->Parameters.Create.ShareAccess |= FILE_SHARE_WRITE;
Data->Iopb->Parameters.Create.ShareAccess |= FILE_SHARE_READ;

and still no success
3. I tried to change the request mode of the user32 app if (
hCurrentProcessID == ProcessIDs[1] ) {
Data->RequestorMode = (KPROCESSOR_MODE)KernelMode;
}
(a long shot and really desperate attempt)

It is more then obvious that the i/o manager and the filter manager
do some kind of validation and forbid such actions!
Any ideas on how I could managed to do that? The code that I use to
lock the file for testing is:

FileStream fs =
File.Open(FileName,FileMode.Open,FileAccess.ReadWrite,FileShare.None);

—
NTFSD is sponsored by OSR

For our schedule debugging and file system seminars (including our new
fs mini-filter seminar) visit:
http://www.osr.com/seminars

You are currently subscribed to ntfsd as: xxxxx@edsiohio.com To
unsubscribe send a blank email to xxxxx@lists.osr.com

—
NTFSD is sponsored by OSR

For our schedule debugging and file system seminars (including our new
fs mini-filter seminar) visit:
http://www.osr.com/seminars

You are currently subscribed to ntfsd as: xxxxx@edsiohio.com To
unsubscribe send a blank email to xxxxx@lists.osr.com

Don_Burn_1 · December 3, 2007, 11:54am

Microsofts file systems do honor the IO_IGNORE_SHARE_ACCESS_CHECK’s it is
of couse the case that for third party file systems they can do what they
want. You can also do the sequence:

ZwOpen( &h, SYNCHRONIZE, … )
ObReferenceObjectByHandle( h, FILE_READ_DATA,
ObOpenObjectByPointer ( … , FILE_GENERIC_READ,

Of course for any of these read is probably ok. The OP want’s write access
and in general that is a big NO NO, since the other application is assuming
it is EXCLUSIVE, so data corruption is highly likely,

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply

“Eric Diven” wrote in message news:xxxxx@ntfsd…
I’m a little fuzzy on how this avoids the sharing access issue. If the
request originates in the kernel, the share access checks are still
made, right? The MSDN suggests that the use of
IO_IGNORE_SHARE_ACCESS_CHECK may not work, because the FS may still
perform the checks itself. Am I incorrect in my understanding about the
share access checks, or is it the case that the FS always does honor the
IO_IGNORE_SHARE_ACCESS_CHECK option?

~Eric

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Monday, December 03, 2007 11:15 AM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] File sharing access

The memory mapping stuff is more for byte range locks, not share modes.
The whole problem can be done without a file system filter at all. I
have in the past created a driver that an application can perform a
create on with actual pathname appended to the driver path. The create
code in the driver, then opens the real file with
IoCreateFileSpecifyDeviceObjectHint overriding
the share checks. On read and writes the driver just performs the file
io
(or if you want to be fancy does it mapped to bypass the byte range
locking).

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply

“Eric Diven” wrote in message
news:xxxxx@ntfsd…
Stupid question, but when you try to add read/write share in approach 2,
do you remember to call FltSetCallbackDataDirty()? I only ask because
I’ve seen doing just that work. This is Q7 on the FAQ, by the way,
which suggests memory mapping the file in the filter driver as an
alternative to taking over the sharing semantics. I’ve got a similar
problem on my plate, and the jury is still out for me as to which
approach I’m going to take.

~Eric

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@abv.bg
Sent: Monday, December 03, 2007 10:34 AM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] File sharing access

Hi,
could someone tell me how I can grand access to specific user32
application.
The idea is that this application should be able to write into a file
that is opened by another application with exclusive access (just the
way my filter driver is able to). I tried some stuff:
1. Creating a handle with OBJ_KERNEL_HANDLE flag in the driver and pass
it to the user32 app but (not surprisingly at all ) the application
threw invalid handle exception.
2. I tried to forcibly change the requested access from other
application to a file, so that no one could open it exclusively:

Data->Iopb->Parameters.Create.ShareAccess |= FILE_SHARE_WRITE;
Data->Iopb->Parameters.Create.ShareAccess |= FILE_SHARE_READ;

and still no success
3. I tried to change the request mode of the user32 app if (
hCurrentProcessID == ProcessIDs[1] ) {
Data->RequestorMode = (KPROCESSOR_MODE)KernelMode;
}
(a long shot and really desperate attempt)

It is more then obvious that the i/o manager and the filter manager
do some kind of validation and forbid such actions!
Any ideas on how I could managed to do that? The code that I use to
lock the file for testing is:

FileStream fs =
File.Open(FileName,FileMode.Open,FileAccess.ReadWrite,FileShare.None);

—
NTFSD is sponsored by OSR

For our schedule debugging and file system seminars (including our new
fs mini-filter seminar) visit:
http://www.osr.com/seminars

You are currently subscribed to ntfsd as: xxxxx@edsiohio.com To
unsubscribe send a blank email to xxxxx@lists.osr.com

—
NTFSD is sponsored by OSR

For our schedule debugging and file system seminars (including our new
fs mini-filter seminar) visit:
http://www.osr.com/seminars

You are currently subscribed to ntfsd as: xxxxx@edsiohio.com To
unsubscribe send a blank email to xxxxx@lists.osr.com

OSR_Community_User · December 4, 2007, 3:41am

10x For the replies. What my driver does is pending read for virtual files and downloads the file that is to be read. Currently the download is done via the driver, meaning that buffers are passed to it and then written to the file, as someone mentioned above. It works perfect, but because of major changes in the architecture of the user32 part of the solution, this way of download is major problem. So in a perfect world I am striving to make it possible for a specific service to download the file without the fear of sharing violation.

Eric_Diven · December 4, 2007, 11:37am

Okay, so to actually implement this, would an approriate approach be to
define a couple of IOCTLs that our existing userland service can use as
an interface to our existing minifilter. I know strictly speaking this
functionality is separate from the minifilter functionality, and could
probably merit a driver of its own, but I’m a little under the gun as
far as time goes.

The minifilter pends operations on the target file until it is restored
to disk by our userland service (which is the one running into the
issues with share access). Like the OP’s situation, we don’t need to
worry about corrupting data on writes, because the process with the
exclusive access is blocked anyway.

Abstractly speaking, the interfaces I would need would be the following:

File_descriptor Create_special (filename) - opens the file in the driver
bypassing share access checks
Write_special (file_descriptor, data, data_length) - writes data into
the file at the end of the file
Close_special (file_descriptor) - closes the file in the driver
Undo_special (file_descriptor) - closes and destorys the file if
something goes wrong on the restore
-possibly-
Restore_security_special (file_descriptor, acl) - apply the acl the the
file as it was when it was backed up

Apart from doing this with IOCTLs, I suppose I could use the minifilter
messaging interface. I’m guessing, however, that this is not meant for
moving large amounts of data between userland and the kernel. Is that a
valid assumption on my part, and if not, should I consider using
messaging instead of IOCTLs?

If IOCTLs are the way to go, how does one ensure that you don’t end up
using somebody else’s FunctionCodes? I’m sure you could cause no end of
trouble if your DeviceType and FunctionCode overlapped somebody else’s
on the same system.

Any thoughts on this would be much appreciated, thanks.

~Eric

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Monday, December 03, 2007 11:15 AM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] File sharing access

The memory mapping stuff is more for byte range locks, not share modes.
The whole problem can be done without a file system filter at all. I
have in the past created a driver that an application can perform a
create on with actual pathname appended to the driver path. The create
code in the driver, then opens the real file with
IoCreateFileSpecifyDeviceObjectHint overriding
the share checks. On read and writes the driver just performs the file
io
(or if you want to be fancy does it mapped to bypass the byte range
locking).

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply

“Eric Diven” wrote in message
news:xxxxx@ntfsd…
Stupid question, but when you try to add read/write share in approach 2,
do you remember to call FltSetCallbackDataDirty()? I only ask because
I’ve seen doing just that work. This is Q7 on the FAQ, by the way,
which suggests memory mapping the file in the filter driver as an
alternative to taking over the sharing semantics. I’ve got a similar
problem on my plate, and the jury is still out for me as to which
approach I’m going to take.

~Eric

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@abv.bg
Sent: Monday, December 03, 2007 10:34 AM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] File sharing access

Hi,
could someone tell me how I can grand access to specific user32
application.
The idea is that this application should be able to write into a file
that is opened by another application with exclusive access (just the
way my filter driver is able to). I tried some stuff:
1. Creating a handle with OBJ_KERNEL_HANDLE flag in the driver and pass
it to the user32 app but (not surprisingly at all ) the application
threw invalid handle exception.
2. I tried to forcibly change the requested access from other
application to a file, so that no one could open it exclusively:

Data->Iopb->Parameters.Create.ShareAccess |= FILE_SHARE_WRITE;
Data->Iopb->Parameters.Create.ShareAccess |= FILE_SHARE_READ;

and still no success
3. I tried to change the request mode of the user32 app if (
hCurrentProcessID == ProcessIDs[1] ) {
Data->RequestorMode = (KPROCESSOR_MODE)KernelMode;
}
(a long shot and really desperate attempt)

It is more then obvious that the i/o manager and the filter manager
do some kind of validation and forbid such actions!
Any ideas on how I could managed to do that? The code that I use to
lock the file for testing is:

FileStream fs =
File.Open(FileName,FileMode.Open,FileAccess.ReadWrite,FileShare.None);

—
NTFSD is sponsored by OSR

For our schedule debugging and file system seminars (including our new
fs mini-filter seminar) visit:
http://www.osr.com/seminars

You are currently subscribed to ntfsd as: xxxxx@edsiohio.com To
unsubscribe send a blank email to xxxxx@lists.osr.com

—
NTFSD is sponsored by OSR

For our schedule debugging and file system seminars (including our new
fs mini-filter seminar) visit:
http://www.osr.com/seminars

You are currently subscribed to ntfsd as: xxxxx@edsiohio.com To
unsubscribe send a blank email to xxxxx@lists.osr.com

Eric_Diven · December 4, 2007, 11:40am

Addendum to the previous - Would anybody recommend any of the samples
specifically as a good place to start looking into this?

Sorry for the redundant email,

~Eric

-----Original Message-----
From: Eric Diven
Sent: Tuesday, December 04, 2007 11:33 AM
To: ‘Windows File Systems Devs Interest List’
Subject: RE: [ntfsd] File sharing access

Okay, so to actually implement this, would an approriate approach be to
define a couple of IOCTLs that our existing userland service can use as
an interface to our existing minifilter. I know strictly speaking this
functionality is separate from the minifilter functionality, and could
probably merit a driver of its own, but I’m a little under the gun as
far as time goes.

The minifilter pends operations on the target file until it is restored
to disk by our userland service (which is the one running into the
issues with share access). Like the OP’s situation, we don’t need to
worry about corrupting data on writes, because the process with the
exclusive access is blocked anyway.

Abstractly speaking, the interfaces I would need would be the following:

File_descriptor Create_special (filename) - opens the file in the driver
bypassing share access checks Write_special (file_descriptor, data,
data_length) - writes data into the file at the end of the file
Close_special (file_descriptor) - closes the file in the driver
Undo_special (file_descriptor) - closes and destorys the file if
something goes wrong on the restore
-possibly-
Restore_security_special (file_descriptor, acl) - apply the acl the the
file as it was when it was backed up

Apart from doing this with IOCTLs, I suppose I could use the minifilter
messaging interface. I’m guessing, however, that this is not meant for
moving large amounts of data between userland and the kernel. Is that a
valid assumption on my part, and if not, should I consider using
messaging instead of IOCTLs?

If IOCTLs are the way to go, how does one ensure that you don’t end up
using somebody else’s FunctionCodes? I’m sure you could cause no end of
trouble if your DeviceType and FunctionCode overlapped somebody else’s
on the same system.

Any thoughts on this would be much appreciated, thanks.

~Eric

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Monday, December 03, 2007 11:15 AM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] File sharing access

The memory mapping stuff is more for byte range locks, not share modes.
The whole problem can be done without a file system filter at all. I
have in the past created a driver that an application can perform a
create on with actual pathname appended to the driver path. The create
code in the driver, then opens the real file with
IoCreateFileSpecifyDeviceObjectHint overriding
the share checks. On read and writes the driver just performs the file
io
(or if you want to be fancy does it mapped to bypass the byte range
locking).

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply

“Eric Diven” wrote in message
news:xxxxx@ntfsd…
Stupid question, but when you try to add read/write share in approach 2,
do you remember to call FltSetCallbackDataDirty()? I only ask because
I’ve seen doing just that work. This is Q7 on the FAQ, by the way,
which suggests memory mapping the file in the filter driver as an
alternative to taking over the sharing semantics. I’ve got a similar
problem on my plate, and the jury is still out for me as to which
approach I’m going to take.

~Eric

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@abv.bg
Sent: Monday, December 03, 2007 10:34 AM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] File sharing access

Hi,
could someone tell me how I can grand access to specific user32
application.
The idea is that this application should be able to write into a file
that is opened by another application with exclusive access (just the
way my filter driver is able to). I tried some stuff:
1. Creating a handle with OBJ_KERNEL_HANDLE flag in the driver and pass
it to the user32 app but (not surprisingly at all ) the application
threw invalid handle exception.
2. I tried to forcibly change the requested access from other
application to a file, so that no one could open it exclusively:

Data->Iopb->Parameters.Create.ShareAccess |= FILE_SHARE_WRITE;
Data->Iopb->Parameters.Create.ShareAccess |= FILE_SHARE_READ;

and still no success
3. I tried to change the request mode of the user32 app if (
hCurrentProcessID == ProcessIDs[1] ) {
Data->RequestorMode = (KPROCESSOR_MODE)KernelMode;
}
(a long shot and really desperate attempt)

It is more then obvious that the i/o manager and the filter manager
do some kind of validation and forbid such actions!
Any ideas on how I could managed to do that? The code that I use to
lock the file for testing is:

FileStream fs =
File.Open(FileName,FileMode.Open,FileAccess.ReadWrite,FileShare.None);

—
NTFSD is sponsored by OSR

For our schedule debugging and file system seminars (including our new
fs mini-filter seminar) visit:
http://www.osr.com/seminars

You are currently subscribed to ntfsd as: xxxxx@edsiohio.com To
unsubscribe send a blank email to xxxxx@lists.osr.com

—
NTFSD is sponsored by OSR

For our schedule debugging and file system seminars (including our new
fs mini-filter seminar) visit:
http://www.osr.com/seminars

You are currently subscribed to ntfsd as: xxxxx@edsiohio.com To
unsubscribe send a blank email to xxxxx@lists.osr.com

David_J_Craig · December 4, 2007, 12:20pm

Communications between your FSMF should be done via a separate device object
which can be secured to some degree. That will eliminate any problems with
IoCtl codes duplicating other drivers’ codes or standard system codes such
as FsCtls. Look at the ‘event’ driver. Also read the OSR threads on kernel
to UM communications. I think there have been some NT Insider articles too.

“Eric Diven” wrote in message news:xxxxx@ntfsd…
Addendum to the previous - Would anybody recommend any of the samples
specifically as a good place to start looking into this?

Sorry for the redundant email,

~Eric

-----Original Message-----
From: Eric Diven
Sent: Tuesday, December 04, 2007 11:33 AM
To: ‘Windows File Systems Devs Interest List’
Subject: RE: [ntfsd] File sharing access

Okay, so to actually implement this, would an approriate approach be to
define a couple of IOCTLs that our existing userland service can use as
an interface to our existing minifilter. I know strictly speaking this
functionality is separate from the minifilter functionality, and could
probably merit a driver of its own, but I’m a little under the gun as
far as time goes.

The minifilter pends operations on the target file until it is restored
to disk by our userland service (which is the one running into the
issues with share access). Like the OP’s situation, we don’t need to
worry about corrupting data on writes, because the process with the
exclusive access is blocked anyway.

Abstractly speaking, the interfaces I would need would be the following:

File_descriptor Create_special (filename) - opens the file in the driver
bypassing share access checks Write_special (file_descriptor, data,
data_length) - writes data into the file at the end of the file
Close_special (file_descriptor) - closes the file in the driver
Undo_special (file_descriptor) - closes and destorys the file if
something goes wrong on the restore
-possibly-
Restore_security_special (file_descriptor, acl) - apply the acl the the
file as it was when it was backed up

Apart from doing this with IOCTLs, I suppose I could use the minifilter
messaging interface. I’m guessing, however, that this is not meant for
moving large amounts of data between userland and the kernel. Is that a
valid assumption on my part, and if not, should I consider using
messaging instead of IOCTLs?

If IOCTLs are the way to go, how does one ensure that you don’t end up
using somebody else’s FunctionCodes? I’m sure you could cause no end of
trouble if your DeviceType and FunctionCode overlapped somebody else’s
on the same system.

Any thoughts on this would be much appreciated, thanks.

~Eric

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Monday, December 03, 2007 11:15 AM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] File sharing access

The memory mapping stuff is more for byte range locks, not share modes.
The whole problem can be done without a file system filter at all. I
have in the past created a driver that an application can perform a
create on with actual pathname appended to the driver path. The create
code in the driver, then opens the real file with
IoCreateFileSpecifyDeviceObjectHint overriding
the share checks. On read and writes the driver just performs the file
io
(or if you want to be fancy does it mapped to bypass the byte range
locking).

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply

“Eric Diven” wrote in message
news:xxxxx@ntfsd…
Stupid question, but when you try to add read/write share in approach 2,
do you remember to call FltSetCallbackDataDirty()? I only ask because
I’ve seen doing just that work. This is Q7 on the FAQ, by the way,
which suggests memory mapping the file in the filter driver as an
alternative to taking over the sharing semantics. I’ve got a similar
problem on my plate, and the jury is still out for me as to which
approach I’m going to take.

~Eric

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@abv.bg
Sent: Monday, December 03, 2007 10:34 AM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] File sharing access

Hi,
could someone tell me how I can grand access to specific user32
application.
The idea is that this application should be able to write into a file
that is opened by another application with exclusive access (just the
way my filter driver is able to). I tried some stuff:
1. Creating a handle with OBJ_KERNEL_HANDLE flag in the driver and pass
it to the user32 app but (not surprisingly at all ) the application
threw invalid handle exception.
2. I tried to forcibly change the requested access from other
application to a file, so that no one could open it exclusively:

Data->Iopb->Parameters.Create.ShareAccess |= FILE_SHARE_WRITE;
Data->Iopb->Parameters.Create.ShareAccess |= FILE_SHARE_READ;

and still no success
3. I tried to change the request mode of the user32 app if (
hCurrentProcessID == ProcessIDs[1] ) {
Data->RequestorMode = (KPROCESSOR_MODE)KernelMode;
}
(a long shot and really desperate attempt)

It is more then obvious that the i/o manager and the filter manager
do some kind of validation and forbid such actions!
Any ideas on how I could managed to do that? The code that I use to
lock the file for testing is:

FileStream fs =
File.Open(FileName,FileMode.Open,FileAccess.ReadWrite,FileShare.None);

—
NTFSD is sponsored by OSR

For our schedule debugging and file system seminars (including our new
fs mini-filter seminar) visit:
http://www.osr.com/seminars

You are currently subscribed to ntfsd as: xxxxx@edsiohio.com To
unsubscribe send a blank email to xxxxx@lists.osr.com

—
NTFSD is sponsored by OSR

For our schedule debugging and file system seminars (including our new
fs mini-filter seminar) visit:
http://www.osr.com/seminars

You are currently subscribed to ntfsd as: xxxxx@edsiohio.com To
unsubscribe send a blank email to xxxxx@lists.osr.com

Gary_Clark_Gary_Clark · December 4, 2007, 5:03pm

Hello,

I’m trying to build an application using Visual Studio
2008 on Vista that
uses the fltUserStructures.h from the ddk6000.

The file contents of fltUserStructures.h differ from
that was XP. I’m having difficulty compiling the
following:

typedef
_struct_bcount(sizeof(INSTANCE_BASIC_INFORMATION) *
InstanceNameLength) struct _INSTANCE_BASIC_INFORMATION
{
ULONG NextEntryOffset;
USHORT InstanceNameLength;
USHORT InstanceNameBufferOffset;
}INSTANCE_BASIC_INFORMATION,*PINSTANCE_BASIC_INFORMATION;

Its stating INSTANCE_BASIC_INFORMATION undeclared.

Any ideas?

Thanks,
Garyc

Eric_Diven · December 7, 2007, 10:53am

Okay, having now cleared other stuff off my plate to work on this, a
couple of questions:

Creating a device appears to be more in the realm of legacy drivers.
Doing IoCreateDevice/Initialize the device object in my minifilter will,
in essence, create a small pseudo-legacy driver that just happens to be
grafted onto my minifilter. Right? (Incidentally, I’m not questioning
your sanity on this point, I’m questioning mine. See question 2 )
Or did I completely misunderstand what you’re suggesting?
Or is there a minifilter way of doing this that I haven’t turned up
via googling?

~Eric

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of David Craig
Sent: Tuesday, December 04, 2007 12:20 PM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] File sharing access

Communications between your FSMF should be done via a separate device
object which can be secured to some degree. That will eliminate any
problems with IoCtl codes duplicating other drivers’ codes or standard
system codes such as FsCtls. Look at the ‘event’ driver. Also read the
OSR threads on kernel to UM communications. I think there have been
some NT Insider articles too.

Don_Burn_1 · December 7, 2007, 10:56am

Take a look at the CDO sample under mini-filters in the WDK.

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply

“Eric Diven” wrote in message news:xxxxx@ntfsd…
Okay, having now cleared other stuff off my plate to work on this, a
couple of questions:

1) Creating a device appears to be more in the realm of legacy drivers.
Doing IoCreateDevice/Initialize the device object in my minifilter will,
in essence, create a small pseudo-legacy driver that just happens to be
grafted onto my minifilter. Right? (Incidentally, I’m not questioning
your sanity on this point, I’m questioning mine. See question 2 )

2) Or did I completely misunderstand what you’re suggesting?

3) Or is there a minifilter way of doing this that I haven’t turned up
via googling?

~Eric

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of David Craig
Sent: Tuesday, December 04, 2007 12:20 PM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] File sharing access

Communications between your FSMF should be done via a separate device
object which can be secured to some degree. That will eliminate any
problems with IoCtl codes duplicating other drivers’ codes or standard
system codes such as FsCtls. Look at the ‘event’ driver. Also read the
OSR threads on kernel to UM communications. I think there have been
some NT Insider articles too.

Eric_Diven · December 7, 2007, 11:02am

Thanks, I was looking at the event driver and wasn’t getting very far
with it.

~Eric

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Friday, December 07, 2007 10:57 AM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] File sharing access

Take a look at the CDO sample under mini-filters in the WDK.

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply

“Eric Diven” wrote in message
news:xxxxx@ntfsd…
Okay, having now cleared other stuff off my plate to work on this, a
couple of questions:

1) Creating a device appears to be more in the realm of legacy drivers.
Doing IoCreateDevice/Initialize the device object in my minifilter will,
in essence, create a small pseudo-legacy driver that just happens to be
grafted onto my minifilter. Right? (Incidentally, I’m not questioning
your sanity on this point, I’m questioning mine. See question 2 )

2) Or did I completely misunderstand what you’re suggesting?

3) Or is there a minifilter way of doing this that I haven’t turned up
via googling?

~Eric

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of David Craig
Sent: Tuesday, December 04, 2007 12:20 PM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] File sharing access

Communications between your FSMF should be done via a separate device
object which can be secured to some degree. That will eliminate any
problems with IoCtl codes duplicating other drivers’ codes or standard
system codes such as FsCtls. Look at the ‘event’ driver. Also read the
OSR threads on kernel to UM communications. I think there have been
some NT Insider articles too.

—
NTFSD is sponsored by OSR

For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars

You are currently subscribed to ntfsd as: xxxxx@edsiohio.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

Eric_Diven · December 7, 2007, 3:17pm

Thanks, the CDO sample has been very helpful as far as how to write the
callbacks and such.
It does raise one question though:

In cdoinit.c in the DriverEntry function, the FLT_REGISTRATION doesn’t
register any callbacks, and the CdoCreateControlDeviceObject registers
IRP and FASTIO dispatch routines into the same DriverObject.

In our filter, we register callbacks in DriverEntry, if I then
initialize some dispatch routines after I do the IoCreateDevice, again,
into the same DriverObject, will I overwrite something the FilterManager
has put there?

In the FileSpy code, the code that handles mounting a new volume, for
instance, doesn’t change the dispatch routines. This seems like a poor
analog, but the only minifilter code that uses IoCreateDevice is the CDO
example.

~Eric

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Friday, December 07, 2007 10:57 AM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] File sharing access

Take a look at the CDO sample under mini-filters in the WDK.

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply

“Eric Diven” wrote in message
news:xxxxx@ntfsd…
Okay, having now cleared other stuff off my plate to work on this, a
couple of questions:

1) Creating a device appears to be more in the realm of legacy drivers.
Doing IoCreateDevice/Initialize the device object in my minifilter will,
in essence, create a small pseudo-legacy driver that just happens to be
grafted onto my minifilter. Right? (Incidentally, I’m not questioning
your sanity on this point, I’m questioning mine. See question 2 )

2) Or did I completely misunderstand what you’re suggesting?

3) Or is there a minifilter way of doing this that I haven’t turned up
via googling?

~Eric

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of David Craig
Sent: Tuesday, December 04, 2007 12:20 PM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] File sharing access

Communications between your FSMF should be done via a separate device
object which can be secured to some degree. That will eliminate any
problems with IoCtl codes duplicating other drivers’ codes or standard
system codes such as FsCtls. Look at the ‘event’ driver. Also read the
OSR threads on kernel to UM communications. I think there have been
some NT Insider articles too.

—
NTFSD is sponsored by OSR

For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars

You are currently subscribed to ntfsd as: xxxxx@edsiohio.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

Eric_Diven · December 7, 2007, 4:10pm

Does the plot ever thicken…

I took a look at the my DriverEntry with the debugger. All of the
dispatch routines for the driver object are initialized to
nt!IopInvalidDeviceRequest, both before and after I call
FltRegisterFilter, and the FastIoDispatch is NULL.

Obiously, the filter manager is handling the calling of the callback
functions you register completely independently of the DRIVER_OBJECT.
Meaning that you can basically write a hybrid minifilter/legacy driver
since there are basically two entry points for everything? Which is, it
appears, exactly what Don proposed, that the CDO sample illustrates
(just without the minifilter half of it).

The more I learn, the weirder it gets.

~Eric

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Eric Diven
Sent: Friday, December 07, 2007 3:17 PM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] File sharing access

Thanks, the CDO sample has been very helpful as far as how to write the
callbacks and such.
It does raise one question though:

In cdoinit.c in the DriverEntry function, the FLT_REGISTRATION doesn’t
register any callbacks, and the CdoCreateControlDeviceObject registers
IRP and FASTIO dispatch routines into the same DriverObject.

In our filter, we register callbacks in DriverEntry, if I then
initialize some dispatch routines after I do the IoCreateDevice, again,
into the same DriverObject, will I overwrite something the FilterManager
has put there?

In the FileSpy code, the code that handles mounting a new volume, for
instance, doesn’t change the dispatch routines. This seems like a poor
analog, but the only minifilter code that uses IoCreateDevice is the CDO
example.

~Eric