I am developing a mini-filter file system for a cifs. I am trying to
FltCreateFile inside of Pre-create callback, and it fails with
STATUS_SHARING_VIOLATION when the dessired access is Read Atributes in
the User level. This is the source code:
InitializeObjectAttributes(&objectAttributes,
&FileName,
OBJ_KERNEL_HANDLE,
NULL,
NULL);
status = FltCreateFile(FilterHandle,
Instance,
FileHandle,
GENERIC_READ|GENERIC_WRITE,
&objectAttributes,
&ioStatus,
(PLARGE_INTEGER) NULL,
FILE_ATTRIBUTE_NORMAL,
FILE_SHARE_READ | FILE_SHARE_WRITE |
FILE_SHARE_DELETE,
FILE_OPEN_IF,
FILE_COMPLETE_IF_OPLOCKED | FILE_WRITE_THROUGH,
NULL,
0L,
IO_IGNORE_SHARE_ACCESS_CHECK);
It works fine with local files, i think that could be a permission
problem related with cifs, but i did not find it.
I hope your help.Thanks you!
I know this has been covered before, but I’ll mention it again:
IO_IGNORE_SHARE_ACCESS_CHECK only works for local files.
From a pragmatic sense, that is reasonable (across the wire we can’t restrict this to “privileged” processes.)
From an implementation sense this is tied into the WAY that this is implemented - it relies upon “secret bits” in the file object AND the use of IoCheckShareAccess (and its related functions.) If you go look at FAT (for example) you will notice it doesn’t have any code to implement this - it’s because it is the OS that implements this via the handshaking in the file object extension. That information isn’t sent across the wire and the remote end wouldn’t (or shouldn’t) respect it, even if it were sent.
Tony
OSR
Hi,
Maybe, your sharing access flags are incompatibles with a previous
createfile. Can you check it out and tell us what is happening?
Cheers,
Pablo
Hello,
The main problem is that the file is previously opened with the
sharing flags configuration that is incompatible with the current
create sharing flags (for the same file).
I’m trying to use
VOID IoSetShareAccess(
__in ACCESS_MASK DesiredAccess,
__in ULONG DesiredShareAccess,
__inout PFILE_OBJECT FileObject,
__out PSHARE_ACCESS ShareAccess
);
in post-create to change sharing access but i’m not able to find the
data structure “ShareAccess”, neither the type.
I have read that the FCB stores (or points to) the share access
structure passed by argument, but i don’t know how to arrive to it and
i didn’t see it in the msdn documentation (FSRTL_ADVANCED_FCB_HEADER).
Thanks
Martin Mu?oz Fernandez
El d?a 6 de mayo de 2010 12:26, Pablo Bol?var Morales
escribi?:
> Hi,
>
> Maybe, your sharing access flags are incompatibles with a previous
> createfile. Can you check it out and tell us what is happening?
>
> Cheers,
>
> Pablo
>
> —
> NTFSD is sponsored by OSR
>
> For our schedule of debugging and file system seminars
> (including our new fs mini-filter seminar) visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>
> The main problem is that the file is previously opened with the
sharing flags configuration that is incompatible with the current
create sharing flags (for the same file).
In that case you are short of luck. As Tony explained the sharing is
arbitrated on the machine serving the files, not on RDR. All you can do is
lie about the sharing access earlier on or not rquire an access mode now.
This of course will cause your application to fail in new and exciting ways.
I’m trying to use
VOID IoSetShareAccess(
__in ACCESS_MASK DesiredAccess,
__in ULONG DesiredShareAccess,
__inout PFILE_OBJECT FileObject,
__out PSHARE_ACCESS ShareAccess
);
Don’t. Thats for file systems, not file system filters.
I have read that the FCB stores (or points to) the share access
structure passed by argument, but i don’t know how to arrive to it and
i didn’t see it in the msdn documentation (FSRTL_ADVANCED_FCB_HEADER).
It might do, it might now. Who knows? that has to be opaque to you.
Anyway, as I mentioned above, the issue is not arbitrated locally.
Lets take a step back. What are you trying to achieve?
Hi Rod,
thanks for the information, i can now understand why it is failing.
I explain what i want to achieve:
given certain file F and it is opened (for the first time) by a
process P with a set of share access flags S (they are set from
process),
- i’d like to change the share access flags (to FILE_SHARE_READ |
FILE_SHARE_WRITE | FILE_SHARE_DELETE) by capturing the IRP Create (pre
or post)
- or, once F has been opened with P share access flags S, next time
i capture another IRP Create i’d like to change (updating) F’s share
access flags (to FILE_SHARE_READ | FILE_SHARE_WRITE |
FILE_SHARE_DELETE).
Thanks for your help, Rod.
Mart?n Mu?oz Fern?ndez.
2010/5/10 Rod Widdowson :
>> The main problem is that the file is previously opened with the
>> sharing flags configuration that is incompatible with the current
>> create sharing flags (for the same file).
>
> In that case you are short of luck. ?As Tony explained the sharing is
> arbitrated on the machine serving the files, not on RDR. ?All you can do is
> lie about the sharing access earlier on or not rquire an access mode now.
> This of course will cause your application to fail in new and exciting ways.
>
>> I’m trying to use
>>
>> VOID IoSetShareAccess(
>> ? in ? ? ACCESS_MASK DesiredAccess,
>> ? in ? ? ULONG DesiredShareAccess,
>> ? inout ?PFILE_OBJECT FileObject,
>> ? out ? ?PSHARE_ACCESS ShareAccess
>> );
>
> Don’t. ?Thats for file systems, not file system filters.
>
>> I have read that the FCB stores (or points to) ?the share access
>> structure passed by argument, but i don’t know how to arrive to it and
>> i didn’t see it in the msdn documentation (FSRTL_ADVANCED_FCB_HEADER).
>
> It might do, it might now. ?Who knows? that has to be opaque to you. Anyway,
> as I mentioned above, the issue is not arbitrated locally.
>
> Lets take a step back. ?What are you trying to achieve?
>
> —
> NTFSD is sponsored by OSR
>
> For our schedule of debugging and file system seminars
> (including our new fs mini-filter seminar) visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
Hello,
is it possible to change share flags when I do a reparse in the
pre-create callback?
I was trying with FltSetCallbackDataDirty() changing
Data->Iopb->Parameters.Create.ShareAccess. But it did not work.
Thanks you!!
2010/5/10 Martin Eduardo :
> Hi Rod,
>
> thanks for the information, i can now understand why it is failing.
>
> I explain what i want to achieve:
> given certain file F and it is opened (for the first time) by a
> process P with a set of share access flags S (they are set from
> process),
>
> ?1) i’d like to change the share access flags (to FILE_SHARE_READ |
> FILE_SHARE_WRITE | FILE_SHARE_DELETE) by capturing the IRP Create (pre
> or post)
> ?2) or, once F has been opened with P share access flags S, next time
> i capture another IRP Create i’d like to change (updating) F’s share
> access flags ?(to FILE_SHARE_READ | FILE_SHARE_WRITE |
> FILE_SHARE_DELETE).
>
> Thanks for your help, Rod.
>
> Mart?n Mu?oz Fern?ndez.
>
>
> 2010/5/10 Rod Widdowson :
>>> The main problem is that the file is previously opened with the
>>> sharing flags configuration that is incompatible with the current
>>> create sharing flags (for the same file).
>>
>> In that case you are short of luck. ?As Tony explained the sharing is
>> arbitrated on the machine serving the files, not on RDR. ?All you can do is
>> lie about the sharing access earlier on or not rquire an access mode now.
>> This of course will cause your application to fail in new and exciting ways.
>>
>>> I’m trying to use
>>>
>>> VOID IoSetShareAccess(
>>> ? in ? ? ACCESS_MASK DesiredAccess,
>>> ? in ? ? ULONG DesiredShareAccess,
>>> ? inout ?PFILE_OBJECT FileObject,
>>> ? out ? ?PSHARE_ACCESS ShareAccess
>>> );
>>
>> Don’t. ?Thats for file systems, not file system filters.
>>
>>> I have read that the FCB stores (or points to) ?the share access
>>> structure passed by argument, but i don’t know how to arrive to it and
>>> i didn’t see it in the msdn documentation (FSRTL_ADVANCED_FCB_HEADER).
>>
>> It might do, it might now. ?Who knows? that has to be opaque to you. Anyway,
>> as I mentioned above, the issue is not arbitrated locally.
>>
>> Lets take a step back. ?What are you trying to achieve?
>>
>> —
>> NTFSD is sponsored by OSR
>>
>> For our schedule of debugging and file system seminars
>> (including our new fs mini-filter seminar) visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
>
Why do you call IoSetShareAccess() directly. It is responsibility of FSD to do that. If your filter doesn’t implement layered FSD you shouldn’t call this API. You can alter sharing flags in preCreate for FSD.
Bronislav Gabrhelik
Hi,
the main problem occurrs when in the Create of a file located over the
network (with the sharing flags set by the application) i try to open
it within the minifilter and as result it fails because of share
acccess flags violation. I have read in OSR documentation some
techniques to cincurvent this sharing access problem (for instance,
using IoCreateFileSpecifyObjectHint(…) ) but i get the same error. I
think these are used for local files, not over the network.
When i perform the Create within the Create for local files i set the
flag IO_IGNORE_SHARE_ACCESS_CHECK and no sharing access is checked.
Could you please help me answer this questions:
* Who is the responsible of checking the sharing access for network
files? If it is the IoManager, why do it differ from local to network
files? Is it the redirector?
* How can i alter the sharing flags for a file in its preCreate? What
API should i use? or Where can i find information about it?
* What i’m developping is a minifilter, what is a layered FSD is?
Thanks for the help.
Mart?n Mu?oz
2010/5/11 :
> Why do you call IoSetShareAccess() directly. It is responsibility of FSD to do that. If your filter doesn’t implement layered FSD you shouldn’t call this API. You can alter sharing flags in preCreate for FSD.
> Bronislav Gabrhelik
>
> —
> NTFSD is sponsored by OSR
>
> For our schedule of debugging and file system seminars
> (including our new fs mini-filter seminar) visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>
As I have said, the FSD is responsible for implementation of share access. Please read comments for IoSetShareAccess on MSDN. The FSD is the highest driver, filters are intermediate drivers. How would you implement mentioned locking, so it is consistent with FSD internal locking mechanism?
Regarding redirector: You know, it is internal thing of the redirector how it implements share access. Even implementation doesn’t have to be done by means of IoSetShareAccess(), IoCheckShareAccess etc.
Layered FSD: It’s hard to explain in several words. If you retain File Object for your FSFD and maintain SCB/CCB/FCB/caching for this FO, so you pass different FO down and FSD below never sees original FO, we can say it is layered FSD. But difficulty is at least equal or above difficulty to implement FSD itself.
Altering shareAccess: I have zero experience with minifilters, but looking into headers for several minutes… I would try modify FLT_CALLBACK_DATA.Iopb.Parameters.Create.ShareAccess in preCreate. The question is if FilterManager copies this field back into IRP’s IO_STACK_LOCATION, before it passes IRP_MJ_CREATE down. It seems that FltSetCallbackDataDirty() ensures that.
Hope this helps.
Bronislav Gabrhelik
Well, don’t forget that the sharing modes on a client-server protocol might
be enforced on the server as well…
There is a difference between how security checks happen on one machine (if
you are kernel, you are trusted) as opposed to over the network (you are not
trusted until you authenticate to the server). The same could happen for
sharing checks (it doesn’t have to be this way, it’s the protocol that
decides that; I’m not that familiar with CIFS but I believe it requires that
the server enforce sharing checks - please double check this!). So it
doesn’t really matter what you can tell IoManager on the local machine since
the server might and should enforce some checks as well…
From your description of the problem it seems that you getting into a
sharing violation with a create you are monitoring (as opposed to a random
create on possibly a different machine). In that case, why not simply use
the user’s FILE_OBJECT ? What is it that you are trying to do with the
handle you want to open ?
Thanks,
Alex.
Hi,
2010/5/11 :
> As I have said, the FSD is responsible for implementation of share access. Please read comments for IoSetShareAccess on MSDN. The FSD is the highest driver, filters are intermediate drivers. How would you implement mentioned locking, so it is consistent with FSD internal locking mechanism?
I don’t currently use any internal locking since i haven’t used
IoSetShareAccess because of it is not used in minifilters drivers,
isn’t it? Is there any chance of using it within a minifilter?
>
> Regarding redirector: You know, it is internal thing of the redirector how it implements share access. Even implementation doesn’t have to be done by means of IoSetShareAccess(), IoCheckShareAccess etc.
>
> Layered FSD: It’s hard to explain in several words. If you retain File Object for your FSFD and maintain SCB/CCB/FCB/caching for this FO, so you pass different FO down and FSD below never sees original FO, we can say it is layered FSD. But difficulty is at least equal or above difficulty to implement FSD itself.
>
> Altering shareAccess: I have zero experience with minifilters, but looking into headers for several minutes… I would try modify FLT_CALLBACK_DATA.Iopb.Parameters.Create.ShareAccess in preCreate. The question is if FilterManager copies this field back into IRP’s IO_STACK_LOCATION, before it passes IRP_MJ_CREATE down. It seems that FltSetCallbackDataDirty() ensures that.
>
I perform a FltCreateFile within a IRP Create for this file over the
network, so the problem is that the second create performed is not
compatible with the first one and it fails. Maybe one solution is
changing IRPCREATE paramaters and perform FltSetCallbackDataDirty(),
as you said, and do all my work in the postcreate.
The ideal solution would be to change share access flags before the
i/o manager trigger the IRP, is it possible to do that?
Thank you.
Martin Munoz.
> Hope this helps.
> Bronislav Gabrhelik
>
>
> —
> NTFSD is sponsored by OSR
>
> For our schedule of debugging and file system seminars
> (including our new fs mini-filter seminar) visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>
Hello
2010/5/11 Alex Carp :
> Well, don’t forget that the sharing modes on a client-server protocol might
> be enforced on the server as well…
>
Yes, I know that.
> There is a difference between how security checks happen on one machine (if
> you are kernel, you are trusted) as opposed to over the network (you are not
> trusted until you authenticate to the server). The same could happen for
> sharing checks (it doesn’t have to be this way, it’s the protocol that
> decides that; I’m not that familiar with CIFS but I believe it requires that
> the server enforce sharing checks - please double check this!). So it
> doesn’t really matter what you can tell IoManager on the local machine since
> the server might and should enforce some checks as well…
Could be, i need to check the server behaviour.
> From your description of the problem it seems that you getting into a
> sharing violation with a create you are monitoring (as opposed to a random
> create on possibly a different machine). In that case, why not simply use
> the user’s FILE_OBJECT ? What is it that you are trying to do with the
> handle you want to open ?
I want to open the file in the create irp for check inside it. But it
seems incompatible by the sharing flags. Can you help me for it?
Thanks you.
> Thanks,
> Alex.
>
>
>
> —
> NTFSD is sponsored by OSR
>
> For our schedule of debugging and file system seminars
> (including our new fs mini-filter seminar) visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>
So why not use the user’s FILE_OBJECT to read the data ?
Thanks,
Alex.
Hi,
this is a good idea, but, can be the data read before the file Create
has finished? I mean, could i read data within the precreate of the
file? how?
Could it be performed triggering a IRP with
FltPerformSynchronousIO(…) for read, set information, write and
another operations.
But how can i do it? taking file object form irp data, or coping or
reussing irp data setting FltSetCallbackdatadirty().
Or maybe is better use io manager routines?
Thanks you!
2010/5/11 Alex Carp :
> So why not use the user’s FILE_OBJECT to read the data ?
>
> Thanks,
> Alex.
>
>
>
> —
> NTFSD is sponsored by OSR
>
> For our schedule of debugging and file system seminars
> (including our new fs mini-filter seminar) visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>
No, it can’t. Even if it were possible, it would probably be pointless. It
is (almost) impossible to reliably know what stream the file system will
open before it actually opens it. Keep in mind the other things that might
happen on a file system such as file and directory renames, setting a
reparse point on a file, closing the last handle on a file that was marked
for deletion, transactions that might commit or rollback which are not easy
to filter. On top of that there are filters below yours that might do all
these things (renames, creates and deletes and so on) which you can’t really
filter anyway. As I said before, filtering an asynchronous stateful protocol
is impossible. You could attempt to serialize the operations that you care
about and the operations that might interfere with those, but you will
probably impact performance in a significant way (since it’s not
asynchronous anymore) and it’s still pretty complicated to get right.
Of course, some filter writers argue that if they don’t read the file in
preCreate it will be too late because the file will already be opened, but
that is not usually a valid point because to anyone above the filter
(minifilters of higher altitudes, IO manager and so on) there should be no
difference between the pre-operation and the post-operation of the filter.
So most filters can simply read file contents in postCreate and then cancel
the file open and fail the create. This usually works well for minifilters
that rely on file contents to decide whether access to a file should be
allowed or not but it is slightly more complicated for filters that look at
paths and so on and need to decide whether creation of a file should be
allowed…
So I guess the next question is why do you think you need to read data in
preCreate ? Are you implementing a security solution ? Why can’t you read it
during postCreate ?
FltPerformSynchronousIo as well as the other FLT routines only work with an
opened FILE_OBJECT. Io manager routines require either a handle or an opened
FILE_OBJECT as well (IIRC)…
Thanks,
Alex.
Hello Alex,
thank you for the help, is very interesting.
So I guess the next question is why do you think you need to read data in
preCreate ? Are you implementing a security solution ? Why can’t you read it
during postCreate ?
I need to read the data before the IRP Create has been completed, so
reading it in the postcreate is a solution but i have to be able to
interrupt Create transparently to the application and redirect to
another file (via Reparse). Is it possible to perform Reparse from
postcreate? If it is, the file is closed before it?
If it is not possible to perform Reparse in postcreate, is it possible
to cancel current create and reissue it to process it again with more
information?
Thank you for the help.
Martin Munoz
“I need to read the data before the IRP Create has been completed” as I
explained previously, this might be rather hard. It also doesn’t answer the
question about what you are trying to do, it only explains what you think
you need to do, which is not the same thing.
You can return STATUS_REPARSE (or any other status for that matter) from
postCreate and you can also call FltCancelFileOpen on the file that was
opened and fltmgr will close it for you.
Thanks,
Alex.
Hello Alex,
I’m sorry for the long time for answer, but I was in holydays!
You are rigth it is for security utility, so it was ok the read in the
postcreate.
Thanks you for you help!
Martin E. Mu?oz
2010/5/14 Alex Carp :
> “I need to read the data before the IRP Create has been completed” as I
> explained previously, this might be rather hard. It also doesn’t answer the
> question about what you are trying to do, it only explains what you think
> you need to do, which is not the same thing.
>
> You can return STATUS_REPARSE (or any other status for that matter) from
> postCreate and you can also call FltCancelFileOpen on the file that was
> opened and fltmgr will close it for you.
>
> Thanks,
> Alex.
>
>
> —
> NTFSD is sponsored by OSR
>
> For our schedule of debugging and file system seminars
> (including our new fs mini-filter seminar) visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>
Hello!
I am doing the reparse in the postcreate, but after in the next create
of reparsed file, i try to Open the original file with fltcreate and
the same flags, and then it returns STATUS_SHARING_VIOLATION! Why is
it happpening??
I think that could be because after reparse the file object is not closed.
Thanks for you help!
Martin Munoz