EldoS | Feel safer!

Software components for data protection, secure storage and transfer

Security Token different in different callbacks

Also by EldoS: Rethync
The cross-platform framework that simplifies synchronizing data between mobile and desktop applications and servers and cloud storages
Posted: 09/30/2013 21:17:38
by Sid Schipper (Standard support level)
Joined: 03/14/2008
Posts: 285

I have definite evidence that the return value from
Sender->GetOriginatorToken() is different in the CbFsCreateFile callback versus for the same file the CbFsWriteFile callback. The evidence I have shows that since my application is running as a system service the security token in the WriteFile callback is the one for the NT AUTHORITY\SYSTEM user, while the one in the CreateFile callback is the one for the user that is creating the file by dragging and dropping it in Windows Explorer. Why would that be the case? It would be nice if the GetOriginatorToken() always returned the token for the user that initiated the request.

I can handle this difference by placing the information that I get from the token into the File Handle Context upon Creation and then using that information in the Write, but I'm not very comfortable with that. Any help you can give me on this topic would be appreciated.
Posted: 10/01/2013 00:03:24
by Eugene Mayevski (EldoS Corp.)

Writing is almost always done by the system cache manager, hence the difference.
There is no reason to inspect who's writing the data.

Sincerely yours
Eugene Mayevski
Posted: 10/01/2013 00:49:41
by Volodymyr Zinin (EldoS Corp.)

Maybe the most "obvious" situation when the security context is different during the file open and writing is the use of memory mapped sections to access file contents. I.e. two customers can open a file in parallel, then both create memory mapped sections to the file and write in parallel to the file memory. During the writing the changes only occur in the memory (in RAM) and at this time there is not any write operations passed to the file system. Later the customers can even close the file. After some short period of time the system component "memory manager" performs flushing the data from the memory to the file. And only this operation causes the write requests to be passed to file system. The security context will be "SYSTEM" at least because the same chunk of the file data can be overwritten in the memory mapped sections several times by both customers.
Posted: 10/07/2013 11:23:08
by Sid Schipper (Standard support level)
Joined: 03/14/2008
Posts: 285

As I said in my original post I can save the stuff I need in the File Handle Context and that works for me, so Thank you for your prompt reply.
Posted: 10/07/2013 11:24:19
by Eugene Mayevski (EldoS Corp.)

Correct, but you won't get that context in file read/write operations.

Sincerely yours
Eugene Mayevski
Also by EldoS: MsgConnect
Cross-platform protocol-independent communication framework for building peer-to-peer and client-server applications and middleware components.



Topic viewed 712 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!