Hi all,
In my mini-filter, I have a case when I need to handle a failed
IRP_MJ_CREATE (specifically, the one with STATUS_ACCESS_DENIED).
I have a post-op handler for that, but when I
call FltGetFileNameInformation() to get the file name, it fails with the
above status.
Should I move the call to the pre-op handler?
Thanks in advance,
G.
Depends on what type of file name you require. IIRC, you can get the
“opened” (not normalized) file in post-create regardless of the status?
If not, get it in pre-create and pass it to your post-create. Unless
you require normalized file name, you should get the “opened” name in
pre-create and only get normalized name in post-create (if it succeeds).
Otherwise, you could get an amazing performance penalty 
Dejan.
Greg wrote:
Hi all,
In my mini-filter, I have a case when I need to handle a failed
IRP_MJ_CREATE (specifically, the one with STATUS_ACCESS_DENIED).
I have a post-op handler for that, but when I
call FltGetFileNameInformation() to get the file name, it fails with
the
above status.
Should I move the call to the pre-op handler?Thanks in advance,
G.
–
Kind regards, Dejan (MSN support: xxxxx@alfasp.com)
http://www.alfasp.com
File system audit, security and encryption kits.
Thanks, Dejan.
So, you say it may depend on whether I ask for a normalized name
(which I actually do)?
I don’t remember seeing it in the documentation.
G.
On Nov 8, 2010, at 19:06, Dejan Maksimovic wrote:
>
> Depends on what type of file name you require. IIRC, you can get
> the
> “opened” (not normalized) file in post-create regardless of the
> status?
> If not, get it in pre-create and pass it to your post-create.
> Unless
> you require normalized file name, you should get the “opened” name in
> pre-create and only get normalized name in post-create (if it
> succeeds).
> Otherwise, you could get an amazing performance penalty
>
> Dejan.
>
> Greg wrote:
>
>> Hi all,
>>
>> In my mini-filter, I have a case when I need to handle a failed
>> IRP_MJ_CREATE (specifically, the one with STATUS_ACCESS_DENIED).
>> I have a post-op handler for that, but when I
>> call FltGetFileNameInformation() to get the file name, it fails with
>> the
>> above status.
>> Should I move the call to the pre-op handler?
>>
>> Thanks in advance,
>> G.
>>
>> —
>
> –
> Kind regards, Dejan (MSN support: xxxxx@alfasp.com)
> http://www.alfasp.com
> File system audit, security and encryption kits.
>
>
>
> —
> 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
Actually, it should not be possible… I forgot - in post-create, FileObject->FileName is invalid, and if the
create did not succeed, FltMgr/filter cannot query the file system for the file name.
So you will need to query it in pre-create. Try to use the “opened” file though, when possible because of the
performance overhead (it is not small at all!)
Greg wrote:
Thanks, Dejan.
So, you say it may depend on whether I ask for a normalized name
(which I actually do)?
I don’t remember seeing it in the documentation.
G.
–
Kind regards, Dejan (MSN support: xxxxx@alfasp.com)
http://www.alfasp.com
File system audit, security and encryption kits.
Strangely enough, when I look into the file object, it appears to be
perfectly fine, including the file name, even if the status is
STATUS_ACCESS_DENIED.
How can it be then?
G.
On Mon, Nov 8, 2010 at 8:05 PM, Dejan Maksimovic wrote:
>
> Actually, it should not be possible… I forgot - in post-create,
> FileObject->FileName is invalid, and if the
> create did not succeed, FltMgr/filter cannot query the file system for the
> file name.
> So you will need to query it in pre-create. Try to use the “opened” file
> though, when possible because of the
> performance overhead (it is not small at all!)
>
> Greg wrote:
>
> > Thanks, Dejan.
> > So, you say it may depend on whether I ask for a normalized name
> > (which I actually do)?
> > I don’t remember seeing it in the documentation.
> > G.
>
> –
> Kind regards, Dejan (MSN support: xxxxx@alfasp.com)
> http://www.alfasp.com
> File system audit, security and encryption kits.
>
>
>
> —
> 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
>
It CAN be fine, however, there is no guarantee it is a valid
UNICODE_STRING pointer. (and there is no way to validate if it is still
allocated pool, or a freed pool that is just still not dereferenced by
the OS).
It’s a rule that FileObject->FileName must not be treated as valid
in post-create.
Greg wrote:
Strangely enough, when I look into the file object, it appears to be
perfectly fine, including the file name, even if the status is
STATUS_ACCESS_DENIED.
How can it be then?
–
Kind regards, Dejan (MSN support: xxxxx@alfasp.com)
http://www.alfasp.com
File system audit, security and encryption kits.
> Strangely enough, when I look into the file object, it appears to be
perfectly fine, including the file name, even if the status is
STATUS_ACCESS_DENIED. How can it be then?
The reason why in this case it appears to be perfectly fine is pure luck. 
As Dejan mentioned, FileObject->FileName is not guaranteed to be valid in post-create. In other words, you should never rely on it because the file system can do whatever it wants with this field.
For instance, when NTFS fails the open of an encrypted file, it will perform _MJ_CLEANUP and _MJ_CLOSE on the fileobject. The IRP_MJ_CLOSE will lead to NTFS setting the FileName->Length field to 1, thus invalidating the name.
Razvan
For example, when a file system (or filter) returns STATUS_REPARSE the name
in FILE_OBJECT.FileName is not the name of the name of the file on disk.
There may be other cases…
Could you please explain what your filter does ? Why do you need the name in
case the create failed ? What do you plan to do with it ?
Thanks,
Alex.
Hi Alex,
The case is pretty simple.
In the beginning, I was interested only in successfully finished operations,
so almost all my handlers were post-ops, including CREATE.
Then, there was a change requiring that one specific case of
STATUS_ACCESS_DENIED be handled as well.
And that’s where I encountered the problem. I was just wondering if I
ultimately had to add the pre-op handler for CREATE.
G.
On Mon, Nov 8, 2010 at 9:27 PM, Alex Carp wrote:
> For example, when a file system (or filter) returns STATUS_REPARSE the name
> in FILE_OBJECT.FileName is not the name of the name of the file on disk.
> There may be other cases…
>
> Could you please explain what your filter does ? Why do you need the name
> in
> case the create failed ? What do you plan to do with it ?
>
> 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
>
Yep, you will have to add it in pre-op.
Greg wrote:
Hi Alex,
The case is pretty simple.
In the beginning, I was interested only in successfully finished
operations,
so almost all my handlers were post-ops, including CREATE.
Then, there was a change requiring that one specific case of
STATUS_ACCESS_DENIED be handled as well.
And that’s where I encountered the problem. I was just wondering if I
ultimately had to add the pre-op handler for CREATE.
–
Kind regards, Dejan (MSN support: xxxxx@alfasp.com)
http://www.alfasp.com
File system audit, security and encryption kits.
Seems so.
Thanks a lot, guys.
G.
On Tue, Nov 9, 2010 at 10:55 AM, Dejan Maksimovic wrote:
>
> Yep, you will have to add it in pre-op.
>
> Greg wrote:
>
> > Hi Alex,
> >
> > The case is pretty simple.
> > In the beginning, I was interested only in successfully finished
> > operations,
> > so almost all my handlers were post-ops, including CREATE.
> > Then, there was a change requiring that one specific case of
> > STATUS_ACCESS_DENIED be handled as well.
> > And that’s where I encountered the problem. I was just wondering if I
> > ultimately had to add the pre-op handler for CREATE.
>
> –
> Kind regards, Dejan (MSN support: xxxxx@alfasp.com)
> http://www.alfasp.com
> File system audit, security and encryption kits.
>
>
>
> —
> 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
>
IMO its pretty dangerous to make any assumption at all after a failure. Consider a filter below you that returns ACCESS_DENIED to mask some other behavior, or consider an access that was blocked because of something towards the top of the (postulate a restrictive ACL on the volume or share). In either case you don’t know that there is a file, you don’t know that the name is valid and there is a good chance that the file name has never been cached/
It seems to me that the *only* thing you can do is due diligence on the provided information in precreate (which is to say FO->FileName and FO->RelatedFileObject. Squirrel this information away and then use it in the failure case. Sure this is extra cycles used on every create, but there has to be some value associated with doing this or you would not be doing it.
If there is no value associated (or the value is less than the cost), just don’t do it or you can just lie and use FO->FileName in postcreate.
Rod
“Greg” wrote in message news:xxxxx@ntfsd…
Hi all,
In my mini-filter, I have a case when I need to handle a failed IRP_MJ_CREATE (specifically, the one with STATUS_ACCESS_DENIED).
I have a post-op handler for that, but when I call FltGetFileNameInformation() to get the file name, it fails with the above status.
Should I move the call to the pre-op handler?
Thanks in advance,
G.
You haven’t actually answered my question about what it is you do with the
name. This is important to establish what the best way to get the name would
be. For example, if you use the name for logging purposed, then getting the
opened name in preCreate should be fine. However, if you plan to retry to
open the stream then you might have a problem since the name might not point
to the same stream it was pointing… Or permissions might change and so on.
When querying for the opened file name in preCreate filter manager will
pretty much exactly what Rob was suggesting (which was to look at
FO->FileName and FO->RelatedFileObject). In terms of performance, this is
much better than querying the normalized name. But then again, which name
you need depends on what you plan to do with it, so I’d say you need to
explain that first.
Thanks,
Alex.
Hi Alex,
The name will be used for logging purposes only.
I decided to use the normalized name in the first place to get
“canonicalized” path, which might be incorrect anyway.
I guess I can do away with the opened name.
G.
On Tue, Nov 9, 2010 at 8:03 PM, Alex Carp wrote:
> You haven?t actually answered my question about what it is you do with the
> name. This is important to establish what the best way to get the name would
> be. For example, if you use the name for logging purposed, then getting the
> opened name in preCreate should be fine. However, if you plan to retry to
> open the stream then you might have a problem since the name might not point
> to the same stream it was pointing… Or permissions might change and so on.
>
>
>
> When querying for the opened file name in preCreate filter manager will
> pretty much exactly what Rob was suggesting (which was to look at
> FO->FileName and FO->RelatedFileObject). In terms of performance, this is
> much better than querying the normalized name. But then again, which name
> you need depends on what you plan to do with it, so I?d say you need to
> explain that first.
>
>
>
> 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
>