EldoS | Feel safer!

Software components for data protection, secure storage and transfer

No HandleInfo argument in OnReadFile/OnWriteFile

Also by EldoS: CallbackProcess
A component to control process creation and termination in Windows and .NET applications.
#30805
Posted: 09/24/2014 10:32:30
by Adam Nie┼╝urawski (Basic support level)
Joined: 09/24/2014
Posts: 1

Hello,

I wonder why CbFsHandleInfo* is not passed to OnReadFile and OnWriteFile callbacks. A context with which the file was open may be necessery there. For example, my remote file system in read/write handlers expects file descriptor which was returned on open call and all open calls have to be distinguishable for some reasons.
Is it possible to do this some way?

Please advise.
Adam
#30806
Posted: 09/24/2014 11:21:12
by Volodymyr Zinin (EldoS Corp.)

In Windows the read and write requests in several cases don't have association with the file opening (file handle). For example:
1. A process opens a file (and CBFS calls the OnOpen callback then).
2. By the use of the obtained file handle the process creates a memory mapped section, for example by means of CreateFileMapping + MapViewOfFile API. CBFS doesn't know about these operations and no one callback is being called at this time.
3. The process closes the handle to the file (and CBFS calls the OnCleanup callback).
4. In the case the memory mapped section has a name, another process can also open this memory mapped section. CBFS again doesn't know about it and therefore doesn't call any callback.
5. The processes start to "copy to" and "copy from" their memory mapped sections. It causes the system memory manager to ask the file system to write/read data to/from the file. CBFS in this case calls the OnRead and OnWrite callbacks, but it doesn't know what a process is the real originator of these requests. Moreover the system memory manager can delay flushing (writing) to the file. I.e. several writings to the memory mapped sections can
occur and these writings can overwrite each other and only then only one write request can come to the file system (i.e. only one the OnWrite callback will be called).
6. After all of the memory mapped sections are closed CBFS calls the OnClose callback.
#30807
Posted: 09/24/2014 11:42:20
by Volodymyr Zinin (EldoS Corp.)

Quote
Adam Nie┼╝urawski wrote:
Is it possible to do this some way?

As a variant you can prevent a file from opening (based either on the requested access rights, or on the name of the process, or the process token) by returning the "access denied" error and it causes the originator process not to obtain a handle to the file and therefore won't be able to perform any operations with the file.
#34514
Posted: 09/21/2015 02:53:09
by William Levra-Juillet (Priority Standard support level)
Joined: 09/05/2013
Posts: 49

Hi Volodymyr,

Sorry to dig up an old thread, but I'm trying to fix issues related to handle and read/write operations.
We switched to using SetCallAllOpenCloseCallbacks(TRUE)
I understand HandleInfo is not a parameter to ReadFile/WriteFile callbacks.

Here is what happens:
- Open file X with GENERIC_READ access (handle h1)
- Open file X with GENERIC_WRITE access (handle h2)
- Open file X with GENERIC_ALL access (handle h3)
So, my file is open 3 times, 3 different handles and 3 different desired access.

Case 1: If a process tries to write to h1 -> it should fail (access denied)
Case 2: If a process tries to read from h2 -> it should fail (access denied)

Without some "context" (other than the FileInfo itself), how are we supposed to process these 2 cases?
Any suggestions?
Thx!
#34515
Posted: 09/21/2015 03:27:23
by Volodymyr Zinin (EldoS Corp.)

Operation system handles these cases itself. It is done in such a way - with each handle the list of access rights is associated and when the process 1 tries to write to the file by the use of h1 the operation system checks whether the handle has access right FILE_DATA_WRITE (it's part of GENERIC_WRITE) and if it isn't present then immediately returns ERROR_ACCESS_DENIED. The file system driver even doesn't receive any request in this case.
But, some kernel mode code (e.g. some antivirus driver) can open a file even with zero access rights and then manually generate "write" request and send it to the file system driver. So in the case of CBFS you still get the OnWrite callback even with the zero access rights handle.
The common practice for file systems is to check access rights during file creation/opening and if the access is denied then return the "access denied" error.
#34516
Posted: 09/21/2015 04:18:02
by William Levra-Juillet (Priority Standard support level)
Joined: 09/05/2013
Posts: 49

Thx Volodymyr, that helps a lot!

In my backend, each open file ("handle") is associated with a file descriptor, which are "persisted" in the handleInfo->UserContext
So, I guess I also have to maintain a list of these descriptors in the FileInfo->UserContext, and pick the right one to perform the read/write operation with the correct descriptor.

Thx for the prompt support.
#35752
Posted: 01/28/2016 11:24:26
by Volodymyr Zinin (EldoS Corp.)

The read and write operations don't have HandleInfo parameter because often it doesn't exists for them. For example a file is opened as a memory mapped section. I.e. a program can open a file (get a handle to it), create a memory mapped section (MapViewOfFile, etc), close the handle (the OnCleanup callback is called at that time), and only then perform read/write by the use of memory mapped section. The read and write requests for this case are not associated with any file handle. Moreover several programs can do the same at the same time and then read/write to the file memory section concurrently. And on the file system level it isn't possible to get information what a program really performed operations.
Also by EldoS: BizCrypto
Components for BizTalk® and SQL Server® Integration Services that let you securely store and transfer information in your business automation solutions.

Reply

Statistics

Topic viewed 4160 times

Number of guests: 1, registered members: 0, in total hidden: 0




|

Back to top

As of July 15, 2016 EldoS Corporation will operate as a division of /n software inc. For more information, please read the announcement.

Got it!