Need a context-specific property bundle for MFTRecord properties

[sbarnum]

From Eoghan Casey:

mftRecord Attribute Range Comment mftFileID xsd:integer mftParentID xsd:integer ntfsInitializedSize xsd:integer mftDeletionCount xsd:integer ntfsHardLinkCount xsd:integer mftResident xsd:boolean 0=resident, 1=non-resident mftRecordChangeTime xsd:dateTimeStamp NTFS record change time ntfsOwnerSID xsd:string ntfsOwnerID xsd:string Represent as Account related to mftRecord mftFlags xsd:integer mftFileNameCreatedTime xsd:dateTimeStamp mftFileNameModifedTime xsd:dateTimeStamp mftFileNameAccessedTime xsd:dateTimeStamp mftFileNameRecordChangeTime xsd:dateTimeStamp mftFileNameLength xsd:integer mftRuns List of (start cluster, length, offset) Represent as ContentData related to mftRecord mftAlternateDataStreamName xsd:string mftAlternateDataStream List of (start cluster, length, offset) Represent as ContentData related to mftRecord (leave security descriptors and compressed/sparse files until next version)

[sbarnum]

Just to ensure I am understanding what you are proposing for the bolded elements, the following is my interpretation (none of the bolded properties would exist natively within the outlined PBs but would rather be expressed on Relationships):

• For ntfsOwnerID
  • You would specify a Trace containing the MftRecord PB to represent the ntfs properties of a file, specify a Trace containing an Account PB characterizing the owning account, specify a Relationship (with kindOfRelationship something like “has-ntfs-owner-id”) with the file trace as the source and the account trace as the target
• For mftRuns
  • You would specify a Trace containing the MftRecord PB to represent the ntfs properties of a file, specify one or more Traces containing a ContentData PB characterizing the data content of the run, specify a Relationship (with kindOfRelationship something like “has-mft-run”) with the file trace as the source and the run contentdata trace as the target
• For mftalternatedatastretms
  • You would specify a Trace containing the MftRecord PB to represent the ntfs properties of a file, specify one or more Traces containing a ContentData PB characterizing the alternate data stream content, specify a Relationship (with kindOfRelationship something like “has-mft-alternate-data-stream”) with the file trace as the source and the alternate data stream contentdata trace as the target
  • I would suggest that the mftAlternateDataStreamName property should also be conveyed within the “name” property of each alternate data stream contentdata trace.

[ajnelson-nist]

I have a concern about mftAlternateDataStream: A file can have multiple alternate data streams. One system file related to the on-disk security database has no primary data stream, and two named alternate data streams.

EDIT: I missed that Sean raised this issue already.

[sbarnum]

From discussion on our phone call this morning (me, Alex, Harm), we think the mftRuns property is not necessary for draft 1.

[sbarnum]

From discussion on our phone call this morning (me, Alex, Harm), we have some consensus on the ntfsOwnerId and mftAlternateDataStream properties.

For ntfsOwnerID Change the type of this property to be a UCO object reference. You would specify a Trace containing the MftRecord PB to represent the ntfs properties of a file, specify a Trace containing an Account PB characterizing the owning account, set the value of the ntfsOwnerID property to be the ID of the account Trace object.

For mftalternatedatastretms, There would be no direct property within the MftRecord PB. You would specify a Trace containing the MftRecord PB to represent the ntfs properties of a file, specify one or more Traces containing the "name" property set to the alternate data stream name and a ContentData PB characterizing the alternate data stream content, specify a "contained-within" Relationship with the file trace as the target and the alternate data stream contentdata trace as the source

[ajnelson-nist]

After writing Issue 6, I had a thought (if I didn't misremember there). Should also have mftStandardInfoCreatedTime (etc.)? Would that be redundant with the timestamp stored in the file property bundle, or reinforcing by illustrating derivation source?

[casework]

For ntfsOwnerID Change the type of this property to be a UCO object reference. You would specify a Trace containing the MftRecord PB to represent the ntfs properties of a file, specify a Trace containing an Account PB characterizing the owning account, set the value of the ntfsOwnerID property to be the ID of the account Trace object.

Overall agree, but to clarify, we are not using the UUID/GUID auto-generated by the documentation as the ntfsOwnerID? Are we using the ID originally defined by the file system and simply making sure both the MFTRecord PB's "ntfsOwnerID" property and Account PB's "identifier" property are the same?

For mftalternatedatastretms, There would be no direct property within the MftRecord PB. You would specify a Trace containing the MftRecord PB to represent the ntfs properties of a file, specify one or more Traces containing the "name" property set to the alternate data stream name and a ContentData PB characterizing the alternate data stream content, specify a "contained-within" Relationship with the file trace as the target and the alternate data stream contentdata trace as the source

Agreed, although what property bundles (if any) would be in the Relationship object? By adding a "AlternateDataStream" property bundle to the Relationship object, we stay consistent with how we show the relationships between files.

Trace1	Relationhip1	Trace2
MFTRecord: - name: null - {metadata}	source: Trace2 target: Trace1 kindOfRelationship: "contained-within"	MFTRecord: - name: "secret_data" - {do we repeat the metadata in Trace1?}
ContentData: - {data for default data stream}	AlternateDataStream: - name: "secret_data"	ContentData: - {data for "secret_data" data stream}

[sbarnum]

I think the clarification/suggestion above for AlternateDataStream looks good with a few clarifications/caveats:

• The "name" property will not be part of the MftRecord PB (as is shown in the table) but on the base Trace object itself.
• The "{metadata}" may be in the MftRecord PB but may also be in other file-related PBs like File.
• Trace2 will not have an MftRecord PB. (It is just the ADS data and not a file itself).
• I would strongly suggest that the ADS trace (Trace2) NOT contain the file metadata from Trace1 as this Trace is not a file but simply a range of data from within the file described in Trace1.

[sbarnum]

This issue looks to be addressed in observable.ttl of v0.3.0

I am not sure exactly when it was added.