EldoS | Feel safer!

Software components for data protection, secure storage and transfer

In memory storage for SolFS

Posted: 09/10/2010 01:44:49
by Abhijit Tannu (Basic support level)
Joined: 09/04/2010
Posts: 4

We want to use SolFS to create a storage in memory such that the files that are created in the storage should vanish once the machine is rebooted.

1. Is this possible with SolFS ? Is yes, what params do we need to select while creating the storage.
2. Is it possible to create the storage once and keep reusing it ? What I mean is that I create the storage which stays even if the machine is rebooted but the data inside the storage is cleared once machine is rebooted ? Is the above possible even when I do not have a drive letter assigned to the storage ? (like z:)
Posted: 09/10/2010 02:04:36
by Alexander Plas (Team)


You should use callback mode. Actually, you have to implement all of the following events (callbacks, delegates):


Please refer to http://www.eldos.com/solfs/articles/4403.php for some additional explanations.

Because in the callback mode there is no files associated with the storage, you have to recreate the storage in memory every time you start to use it.
Posted: 09/10/2010 02:22:26
by Eugene Mayevski (Team)

What is the reason of keeping the storage, if it loses the data during reboot? And what do you define as storage in this case? If you just need a mointing point, take a look at Callback File System (CBFS). It provides a virtual file system, where you define the container and it's contents. And CBFS just forwards OS requests for data to your code. CBFS also has a sample for in-memory virtual disk, called VDisk. Maybe it will fit your needs better, than SolFS, because SolFS' main purpose is to provide a persistent container.

Sincerely yours
Eugene Mayevski
Posted: 09/10/2010 08:56:53
by Abhijit Tannu (Basic support level)
Joined: 09/04/2010
Posts: 4

Let me explain you what we are trying to achieve and you can suggest me the best option.
1. We want to create a file which should appear as a normal file to an application. (It is better that the file is on the disk unless you have some option by which we do not need to implement the call back APIs to create and manage files in memory)
2. The file should be accessible only from the process that created it (and child processes). No other application should be able to access the file content.
3. Ideally, the file should also be hidden from all other processes.
4. The file should be not accessible (or only encrypted data should be visible) in following cases -
a. While the process is running, some other process tries to access the file using the same mount point.
b. While the process is running, some other process goes and reads the .st file. (Encrypting the storage will probably take care of this)
c. The process is killed by the user and not allowed to terminate normally. Some other process then tries to access the file by mounting the same storage or using the same mount point. (The process may also grant itself permissions using AddGrantedProcess)
d. While the process that created the file is running, user switched off the machine. Then the machine was restarted, the same storage was mounted by another process and tried to access the file.
5. The storage can have only hidden mount point which is not visible as drive letter.
6. The storage can be encrypted.
7. We can create separate storage for each process, if required. (Although we will like to avoid this).
8. Is there an option by which the data written on the storage is not accessible to anyone in the world by whatever means once the application closes. (May be the encryption key for the data is lost once application closes)
9. Can we achieve #8 above at the file level instead of storage level.

In our case, the application is creating some sensitive data during processing which needs to be protected from any malacious intent of the user running the application. The data should be deleted or wiped out or made unaccessible once the application closes.
Posted: 09/10/2010 09:21:36
by Eugene Mayevski (Team)

Well, items 1-7 are achievable with both SolFS OS edition and Callback File System. SolFS requires less coding, while CBFS provides more control and additional functionality (you can store files separately from each other). For your particular task both SolFS and CBFS offer almost the same functionality.

Now about your overall task: if the data is generated and kept in memory, it can be stolen by other process. There exist ways and solutions (for example, we have a function in our RawDisk product for this) to capture all memory of computer, no matter what application it belongs to. So there's always a risk that the data leaks. This is a consequence of the fact, that the computer is not in your posession, and whatever you give away (or produce remotely), related to this computer, is not in your posession anymore as well. You can only reduce the risk of leakage of this information. So the question is how important the data is, and what are the risks of losing it.

Sincerely yours
Eugene Mayevski



Topic viewed 3402 times

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


Back to top

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

Got it!