EldoS | Feel safer!

Software components for data protection, secure storage and transfer

Regarding GetOriginator* usage

Also by EldoS: RawDisk
Access locked and protected files in Windows, read and write disks and partitions and more.
#32881
Posted: 04/01/2015 14:28:06
by Stelios Mavridis (Basic support level)
Joined: 01/09/2015
Posts: 34

As the title suggests i am not sure on where to call GetOriginator* functions and how to 'remember' the returned values
, in the documentation you say:

Quote

Instead do the following:

1) Call GetOriginatorProcessName from OnCreateFile or OnOpenFile event handlers / callbacks;
2) Store obtained information somewhere and store the reference to this information in the UserContext;
3) When you need to check the originator information in some file-related callback, access the stored information via UserContext


I am confused at 1 and 2.

i) As OnCreateFile and OnOpenFile do not have a UserContext arguement how can achieve two?
ii) Can i use GetOriginator* functions in OnPostCreateFile and OnPostOpenFile functions?
iii) If (ii) is not possible then how will i achieve 2?
I assume a file can be opened concurrently from multiple users, so storing on a Dictionary with filenames as keys wont
work.

Thank you for your replies.
#32882
Posted: 04/01/2015 14:40:18
by Vladimir Cherniga (EldoS Corp.)

Quote
ii) Can i use GetOriginator* functions in OnPostCreateFile and OnPostOpenFile functions?

Yes, for sure. You may use it in post-operation callback and keep it safely in UserContext associated storage. Additionally, you should keep a reference count in order to find a condition when user context must be freed in OnCloseFile callback.
#32883
Posted: 04/01/2015 14:48:50
by Stelios Mavridis (Basic support level)
Joined: 01/09/2015
Posts: 34

Ok thank you very much for clarifying that.
#33539
Posted: 06/03/2015 11:23:34
by Stelios Mavridis (Basic support level)
Joined: 01/09/2015
Posts: 34

Hello again,

Just to be certain.
The user context is per file or per User per File?
To clarify, if i have two users(over a file share) accessing the same file, will they both see the same UserContext(so per file) or will each user have a different UserContext(so per User per File)?
#33540
Posted: 06/03/2015 14:56:15
by Vladimir Cherniga (EldoS Corp.)

User context is a per file value. It it alive between first open/create request and last close.
#33541
Posted: 06/03/2015 15:05:22
by Stelios Mavridis (Basic support level)
Joined: 01/09/2015
Posts: 34

Quote

User context is a per file value. It it alive between first open/create request and last close.


I understand that, but i am asking when multiple users open the same file.
Consider the following:

[user1 opens file test.txt and sets UserContext]
[user2 opens file test.txt]
[user2 closes file test.txt]
[user1 closes file test.txt]

Will user2 be able to access the UserContext set by user1?
#33542
Posted: 06/03/2015 15:17:00
by Vladimir Cherniga (EldoS Corp.)

Quote
Stelios Mavridis wrote:
Will user2 be able to access the UserContext set by user1?

I don't understand who is the user1 and user2. User context is the same withing single filter instance. It doesn't matter who opens the file. Withing filter instance user context not changed. If you create another filter instance, then you will get another unique per-file value of user context.
#33543
Posted: 06/03/2015 16:03:03
by Eugene Mayevski (EldoS Corp.)

The user doesn't set context. Your code sets UserContext field and your code is executed in system context in which it was started, not in the context of the caller user. Does this answer your question or I've missed? :)


Sincerely yours
Eugene Mayevski
#33544
Posted: 06/03/2015 16:39:46
by Stelios Mavridis (Basic support level)
Joined: 01/09/2015
Posts: 34

Quote

The user doesn't set context. Your code sets UserContext field and your code is executed in system context in which it was started, not in the context of the caller user. Does this answer your question or I've missed? :)


Not really, but it did make me see that my phrasing could be confusing.
Let me rephrase.

I have a CallbackFilter filtering a directory shared through windows share.
We can find the user that issued the IO in the OpenCallback using GetOriginatorToken, this however is not possible in other callbacks (eg ReadCallback) as you correctly pointed out.

I however have to be able to find the user of a read operation, as different users should get different data/behaviour(eg fail).

I was asking if the UserContext parameter of the ReadCallback is per file, in which case two different users (the user1,user2 in the previous post) would get the same UserContext pointer.

The other scenario is that the UserContext parameter of the ReadCallback is per file and per user.
In that case the two users will get a different UserContext pointer.

I really hope this resolves any confusion caused from the previous post.

Thank you
#33545
Posted: 06/03/2015 16:54:22
by Eugene Mayevski (EldoS Corp.)

Thank you for the clarification.

Unfortunately it's the system-imposed restriction that all readers of the same file must get the same data. This is because of the system cache. Here's how it works:

The data goes this way:

FS -> FS filter -> system cache -> OS Filesystem API -> Application

The cache is common for all applications. Requests for reading and writing the data do not contain identifier of the calling process because it can be the system itself, filling the cache.

You can control which process opens the file and prevent file opening (if the file can't be opened, it can't be read by the process). But once the file is opened, the process reads the data from the cache or via the cache, but you don't control this on Cache<->Application route.


Sincerely yours
Eugene Mayevski
Also by EldoS: CallbackRegistry
A component to monitor and control Windows registry access and create virtual registry keys.

Reply

Statistics

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