Strange permissions issue with ifstest.exe

NTFSD
1

Hi all,

I am using ifstest.exe to test my ifs. I am running across something I
cannot explain in the SimpleRenameInformationTest.

Ifstest.exe creates a file named \fileinfo\srename. It then closes the file,
and I see a cleanup and a close.

It then opens the file again, with only Delete and Synchronize access
requested.

After that, it does a FASTIO_QUERY_BASIC_INFO for FileAttributeInformation.
This succeeds on NTFS and it fails on my IFS.

However, I don’t understand why it succeeds on NTFS. Since the caller hasn’t
requested any read access, it seems to me that the query should fail with
access denied.

Can anyone tell me what I am missing here?

Thanks,

Don

2

Don,

If this is a bug, it would be one in the I/O Manager. It is not the
file system’s responsibility to determine the required access here, but
rather the I/O Manager (which defines the rights required to perform a
particular operation).

In the case you cite, however, the I/O Manager should fail the request
because the caller needs to have FILE_READ_ATTRIBUTES access. So,
either this is a bug in the I/O Manager (walk through
NtQueryInformationFile) or you are misreading the access that was
granted against the open file instance.

Of course, my question would be: why are you checking security here
anyway? Given that this is an OS responsibility, not an FSD
responsibility, the reason you see this failure is that you are adding a
check that is not present in NTFS or FAT. If you also relied upon the
OS to do this check, then you would see the same behavior.

Oh, FYI: this might be related to the OS version and whether or not you
are doing this operation over the network or running locally.

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

Looking forward to seeing you at the Next OSR File Systems Class
October, 2005 in Palo Alto, CA!

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don
Sent: Monday, June 13, 2005 4:47 PM
To: ntfsd redirect
Subject: [ntfsd] Strange permissions issue with ifstest.exe

Hi all,

I am using ifstest.exe to test my ifs. I am running across something I
cannot explain in the SimpleRenameInformationTest.

Ifstest.exe creates a file named \fileinfo\srename. It then closes the
file,
and I see a cleanup and a close.

It then opens the file again, with only Delete and Synchronize access
requested.

After that, it does a FASTIO_QUERY_BASIC_INFO for
FileAttributeInformation.
This succeeds on NTFS and it fails on my IFS.

However, I don’t understand why it succeeds on NTFS. Since the caller
hasn’t
requested any read access, it seems to me that the query should fail
with
access denied.

Can anyone tell me what I am missing here?

Thanks,

Don

Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

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

3

> It then opens the file again, with only Delete and Synchronize access

requested.
After that, it does a FASTIO_QUERY_BASIC_INFO for
FileAttributeInformation. This succeeds on NTFS and it fails on my IFS.

Interesting. What operating system do you use ?
I tried FileTest on WinXP SP2. I opened a file using NtCreate
for DELETE | SYNCHRONIZE access, then I tried to query
the FileBasicInformation and it returned STATUS_ACCESS_DENIED.

FileSpy showed no request coming to the FSD, so the
status must have been returned by the I/O manager
itself.

L.

4

Hello Don,

Could you post the IFSTest output when running versus your fsd? I assume
IFSTest is blaming you for non-NTFS behavior but you think your behavior is
right. Is your fsd implementing NTFS or (more likely) UDF?

Best regard,

David Burg.

Subject: Strange permissions issue with ifstest.exe
From: “Don”
Date: Mon, 13 Jun 2005 16:46:48 -0400
X-Message-Number: 10

Hi all,

I am using ifstest.exe to test my ifs. I am running across something I
cannot explain in the SimpleRenameInformationTest.

Ifstest.exe creates a file named \fileinfo\srename. It then closes the file,

and I see a cleanup and a close.

It then opens the file again, with only Delete and Synchronize access
requested.

After that, it does a FASTIO_QUERY_BASIC_INFO for FileAttributeInformation.
This succeeds on NTFS and it fails on my IFS.

However, I don’t understand why it succeeds on NTFS. Since the caller hasn’t

requested any read access, it seems to me that the query should fail with
access denied.

Can anyone tell me what I am missing here?

Thanks,

Don

5

Hi,

Thanks for all your responses. I have a little more information.

As Lanislav pointed out, if you do an NTCreateFile with these permissions
and then attempt to do an NtQueryInformationFile, it fails. However, if I
look at the IRPs coming down to the IFS, I really do see an IRP as described
below. The file is opened with Delete and Synchronize. There is then a
FASTIO_QUERY_BASIC_INFO (followed by an IRP to do the same thing if the
fastio fails). This IRP is serviced by NTFS and all is well.

Tony was right that I was making tests that I didn’t need to. If I don’t
check this (I thought I was supposed to) my IFS passes also.

So what is interesting is that somehow ifstest.exe is getting what should be
an illegal IRP down to the IFS.

I think this is happening because NtQueryInformationFile is not being
called. I think some other NT… call is being made that then bypasses the
normal security checking. The QueryBasicInfo comes immediately before a
IRP_MJ_SET… for FileRename, so I think there must be some rename function
that first does a query, followed by a set. Somehow the query bypasses the
IoManager security checks.

It is really easy to see this behavior. Run ifstest.exe and run the
SimpleRenameInformationTest while using FileMon or FileSpy to look at the
IRPs. You will see this FASTIO request come down as described, even though
it should not be possible for it to do so. I have attached a snippet from
FileMon to show this behavior. This test was run on NTFS. The command line
was:

start /wait ifstest.exe /t SimpleRenameInformationTest F: /r C: /n
.\PALResults.log /N 356789AB

The open is line 751 and the query is in line 755

Line 754 is also interesting. I wouldn’t have thought that you could open
the volume itself with delete access, but there it is.

751 12:37:15 PM ifstest.exe:4092 IRP_MJ_CREATE F:\fileinfo\srename.dat
SUCCESS Options: Open Access: Delete
752 12:37:15 PM ifstest.exe:4092 IRP_MJ_CREATE F:\fileinfo\srename2.dat
SUCCESS Options: Open Access: Delete
753 12:37:15 PM ifstest.exe:4092 IRP_MJ_CREATE F:\fileinfo\srename SUCCESS
Options: Open Access: Delete
754 12:37:15 PM ifstest.exe:4092 IRP_MJ_CREATE F: SUCCESS Options: Open
Access: Delete
755 12:37:15 PM ifstest.exe:4092 FASTIO_QUERY_BASIC_INFO
F:\fileinfo\srename.dat SUCCESS Attributes: A
756 12:37:15 PM ifstest.exe:4092 IRP_MJ_CREATE F:\fileinfo\emaners.dat
SUCCESS Options: Open Access: All
757 12:37:15 PM ifstest.exe:4092 IRP_MJ_SET_INFORMATION
F:\fileinfo\srename.dat SUCCESS FileRenameInformation

My IFS is attempting to emulate NTFS.

Thanks,

Don

“Don” wrote in message news:xxxxx@ntfsd…
> Hi all,
>
> I am using ifstest.exe to test my ifs. I am running across something I
> cannot explain in the SimpleRenameInformationTest.
>
> Ifstest.exe creates a file named \fileinfo\srename. It then closes the
> file, and I see a cleanup and a close.
>
> It then opens the file again, with only Delete and Synchronize access
> requested.
>
> After that, it does a FASTIO_QUERY_BASIC_INFO for
> FileAttributeInformation. This succeeds on NTFS and it fails on my IFS.
>
> However, I don’t understand why it succeeds on NTFS. Since the caller
> hasn’t requested any read access, it seems to me that the query should
> fail with access denied.
>
> Can anyone tell me what I am missing here?
>
> Thanks,
>
> Don
>
>
>
>
>