Skip to content
Snippets Groups Projects
Commit 87d557ec authored by Richard Cordovano's avatar Richard Cordovano
Browse files

Update OS account dox

parent d88459a2
No related branches found
No related tags found
No related merge requests found
...@@ -64,13 +64,13 @@ We recommend that the OS account addresses or names that were parsed from the da ...@@ -64,13 +64,13 @@ We recommend that the OS account addresses or names that were parsed from the da
There are three unique elements to creating and updating OS accounts when adding data to the case database: There are three unique elements to creating and updating OS accounts when adding data to the case database:
<ol> <ol>
<li>When creating and updating OS accounts in the case database, you need to avoid some pitfalls involving doing a lot of work in a transaction. Why? For single-user cases, if you have created a org.sleuthkit.datamodel.SleuthkitCase.CaseDbTransaction, you should never call another database access method unless it allows you to pass in the CaseDbTransaction you are using. Otherwise, the method that you call will attempt to create its own transaction and because you already have the underlying SQLite case database locked, the called method will block forever waiting for a lock it cannot obtain. For a multi-user case, you will run the risk of attempting to create rows in the case database that would duplicate rows created by another user on another machine. In this scenario, uniqueness constraints will cause your entire transaction to fail and everything you have done up to that point will be rolled back and will have to be redone. <li>When creating and updating OS accounts in the case database, you need to avoid some pitfalls involving doing a lot of work in a transaction. Why? For single-user cases, if you have created a org.sleuthkit.datamodel.SleuthkitCase.CaseDbTransaction, you should never call another database access method unless it allows you to pass in the CaseDbTransaction you are using. Otherwise, the method that you call will attempt to create its own transaction and because you already have the underlying SQLite case database locked, the called method will block forever waiting for a lock it cannot obtain. For a multi-user case, you will run the risk of attempting to create OS accounts in the case database that would duplicate accounts created by another user on another machine. In this scenario, uniqueness constraints will cause your entire transaction to fail and everything you have done up to that point will be rolled back and will have to be redone.
This means that if you want to use a CaseDbTransation to add a lot of files or artifacts associated with OS accounts, you'll need to: This means that if you want to use a CaseDbTransation to add a lot of files or artifacts associated with OS accounts, you'll need to:
<ol type="a"> <ol type="a">
<li>Pre-process the data to identify what OS accounts you need to find references to <li>Pre-process the data to identify what OS accounts you need to create or look up
<li>See if the OS Accounts already exist and update them, if appropriate, or make new ones <li>Look up or create the OS accounts in individual transactions
<li>Start the transaction and add the files and artifacts with the refrences to the OS accounts <li>Start a new transaction and add the files or artifacts with the references to the OS accounts
</ol> </ol>
<li>You need to check if you have more information than what is already stored (e.g., maybe the realm name was unknown). <li>You need to check if you have more information than what is already stored (e.g., maybe the realm name was unknown).
......
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Please register or to comment