#1728 Extract user SID, username and Full name

[hauck-jvsh]

No description provided.

[lfcnassif]

Question to other DEVs:

Should we create new ownerSID, ownerLogin, ownerFullName properties or reuse the existing userAccount, userName and create a new userSID extra property? Last ones currently are used by some parsers (WhatsApp, Telegram, Vcard, etc) to populate information about contacts and also about the app user/owner account.

[hauck-jvsh]

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?

[lfcnassif]

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:
#1195

For now, what about using a simple fs or fs: prefix?

[hauck-jvsh]

For now, what about using a simple fs or fs: prefix?

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.

[hauck-jvsh]

Do you add the prefix or should I add?

[lfcnassif]

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 ownerSID -> fs:ownerID

[hauck-jvsh]

Do you have a small test image with EXT{N} file system?

[lfcnassif]

You should find some here: https://cfreds.nist.gov/

[lfcnassif]

We can also populate owner info into FolderTreeReader class when processing a mounted folder using Files.getOwner(...). Not sure if this info is already decoded from AD1, it can be useful too, could you clarify to us @gfd2020?

[gfd2020]

We can also populate owner info into FolderTreeReader class when processing a mounted folder using Files.getOwner(...). > Not sure if this info is already decoded from AD1, it can be useful too, could you clarify to us @gfd2020?

Yes, if I'm not mistaken, but it depends on the type of capture performed by the FTK Imager.
If the source is 'Contents of a Folder', the files will only have basic properties.

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.
However, only a few properties are being addressed now. They are defined by codes.
'Ower SID' is 40967 for example. In this case, there would have to be a treatment of this code in the java FileHeader class.

Did I manage to answer the question?

[hauck-jvsh]

We can also populate owner info into FolderTreeReader class when processing a mounted folder using Files.getOwner(...). Not sure if this info is already decoded from AD1, it can be useful too, could you clarify to us @gfd2020?

I think that there is already a code to extract the owner in FolderTreeReader.

try {
      UserPrincipal owner = Files.getOwner(path);
      if (owner != null)
          item.setExtraAttribute(FS_OWNER, owner.toString());

  } catch (IOException e) {
      e.printStackTrace();
  }

Am I wrong? Do you record this?

[lfcnassif]

All these properties are read by the readProperty parser function.
However, only a few properties are being addressed now. They are defined by codes.
'Ower SID' is 40967 for example. In this case, there would have to be a treatment of this code in the java FileHeader class.
Did I manage to answer the question?

Yes, perfect! Seems pretty straightforward to read this property then, thank you!

I think that there is already a code to extract the owner in FolderTreeReader.

try {
      UserPrincipal owner = Files.getOwner(path);
      if (owner != null)
          item.setExtraAttribute(FS_OWNER, owner.toString());

  } catch (IOException e) {
      e.printStackTrace();
  }

Am I wrong? Do you record this?

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.

[lfcnassif]

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 --addowner in the command line. That's because reading this property when processing a network share takes a lot of time and it is an important use case in the field. Should we remove that option and always read the owner property? Invert the option to read by default and allow to avoid reading it? If you weren't aware about that option, possibly users aren't too, so, what is the better default behavior for most users not aware about that option?

[hauck-jvsh]

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.

[lfcnassif]

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.

[hauck-jvsh]

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.

[lfcnassif]

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!

[lfcnassif]

It could go to conf/FileSystemConfig.txt