-
Notifications
You must be signed in to change notification settings - Fork 217
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
#1728 Extract user SID, username and Full name #1729
base: master
Are you sure you want to change the base?
Conversation
Question to other DEVs: Should we create new |
I think it is better to maintain info coming from the file system apart from those coming from parsers, maybe a better name to make more explicit that these are coming the files system what do you think? |
Makes sense, like proposed here: For now, what about using a simple |
I think that this will solve for now. As for the more general change, I think it can be done, but maybe some important features may be presented in a tab separated for them. As the name, path and hash for example. |
Do you add the prefix or should I add? |
You can, I prefer the one with a colon to keep the pattern of other properties and thinking on #1195 in the future. But before merging, I think we should take a look at EXT3/4 owner related attributes, maybe we can use more general property names to support both NTFS and EXTN attributes at the same time, like renaming |
Do you have a small test image with EXT{N} file system? |
You should find some here: https://cfreds.nist.gov/ |
We can also populate owner info into |
Yes, if I'm not mistaken, but it depends on the type of capture performed by the FTK Imager. If the source is "Logical Drive" or "Physical Drive", the files will have various file system properties (only tested for NTFS). The 'Ower SID' is one of them. All these properties are read by the readProperty parser function. Did I manage to answer the question? |
I think that there is already a code to extract the owner in FolderTreeReader.
Am I wrong? Do you record this? |
Yes, perfect! Seems pretty straightforward to read this property then, thank you!
Sorry, you're right, I added this a long ago and forgot about it. Maybe we can populate both properties to keep backwards compatibility, deprecate and remove the old one in a future release. |
Question to other DEVs: currently the owner property, when processing mounted folders, is added just if user passes the |
I think, that it is better to add the owner info by default, and makes an option to disable. As you say processing files over the network is an important use, but is often done automatically. This, in average, makes the time not so import, if a specific task is taking too much time the user can restart it disabling the option. |
I wasn't clear. If processing network shares using fastmode, transversing the network share becomes much slower. I don't remember the number but it is something like 3x or more... So, at least for fastmode, it makes a big difference, since file content is not processed. |
So maybe changing to a profile parameter only disabled by default in fastmode. Just to make it more clear we could print a message in the terminal warning that the owner and other properties will not be extracted in case it is disabled. |
This is a good idea! |
It could go to conf/FileSystemConfig.txt |
No description provided.