About the Exclusion Attribute for Files Matching an Exclusion Key Rule
Files matching an exclusion key rule have the status rekey_excluded
in the CTE-LDT attribute. For more information about CTE-LDT attributes, see CTE-LDT Metadata in Extended Attributes. To check for the exclusion attribute on a file, see Determining if a File is Included in an Exclusion Key Rule.
The Exclusion Attribute is not Persistent
Exclusion from rekey is no longer a persistent property as of v7.6.0.
See Dynamic Resource Set for more information.
Determining if a File is Included in an Exclusion Key Rule
Use the voradmin ldt attr get <path to file>
command to check whether a file is associated with an exclusion key rule.
-
On Linux, an excluded file will include the status
rekey_excluded
in thevoradmin
output. For example:voradmin ldt attr get /oxf-fs1/gp1/foo.txt CTE-LDT attributes: rekeyed_size=0, rekey_status=rekey_excluded
-
On Windows, an excluded file will include the attribute
Rekey Status Excluded
in thevoradmin
output. For example:C:\> voradmin ldt attr get c:\gp1\foo.txt CTE-LDT attributes: Rekey Status Excluded Initial Rekeyed Size 9 Bytes Data Transformed 0 Bytes Key: Current Key Name/Version (Clear_Key) New Key Name/Version (Clear_Key)
Removing the Exclusion Attribute From a File
To disassociate a file from an exclusion key rule, you must copy the file to a new file that is not associated with the resource set, or exclusion key rule, of that same source file. You can then remove the original file. The new file is created under the default key rule of whatever policy applies to the new file. Moving or renaming a file does not disassociate a file from an exclusion key rule.
For example, assume the following exclusion key rule where Key_TextFiles
is a non-versioned key:
Exclusion Key Rule: Resource set =*.txt
, Key = Key_TextFiles
If you copy the file test1.txt
to test1.foo
, test1.foo
is created with whatever key is specified in the policy that matches the new file. The key for the new file could be a non-versioned key, versioned key, clear_key, or, no key at all if the new file is outside of a GuardPoint. The original file test1.txt
remains unchanged and encrypted with the Key_TextFiles
non-versioned key because the file remains in the exclusion key rule.
Rename and Restore Operations (Linux)
The effect of rename, or backup/restore operations, involving files associated or excluded with exclusion key rules, is complex. In some cases, the operations to restore, or rename, causes conflicts between the key associated with the source file, and the key associated with the target file. For example, the result of a rename operation involving a source file, not associated with an exclusion key rule, and target file name associated with a resource set of an exclusion key rule is different from the result of the same operation when the target file name is associated with the resource set of an exclusion key rule with clear_key.
Note
Be sure to review the effect of the operations below and avoid administrative operations that cross associations of files across multiple resource sets with conflicting key rules.
Backup/Restore
The table below illustrates the status and the key effect of restore operations involving mixed keys associated with source files from backup image and existing target files inside GuardPoint.
Key Applied to File in Backup | Key Applied to existing file in GuardPoint | Key Effect of Restore Operation on Existing file |
---|---|---|
Versioned | Versioned | Versioned |
Versioned | Exclusion key | xattr_error (failed) |
Versioned | Exclusion clear key | xattr_error (failed) |
Exclusion key | Versioned | Exclusion key |
Exclusion key | Exclusion key | Exclusion key |
Exclusion key | Exclusion clear key | xattr_error (failed) |
Exclusion clear key | Versioned | Exclusion clear key |
Exclusion clear key | Exclusion key | xattr_error (failed) |
Exclusion clear key | Exclusion clear key | Exclusion clear key |
The table below illustrates the status and the key effect of restore operations involving mixed keys associated with source files from backup image and new target files not present inside GuardPoint.
Key Applied to File in Backup | Key Applied to existing file in GuardPoint | Key Effect of Restore Operation on Existing file |
---|---|---|
Versioned | Versioned | Versioned |
Versioned | Exclusion key | xattr_error (failed) |
Versioned | Exclusion clear key | xattr_error (failed) |
Exclusion key | Versioned | Exclusion key |
Exclusion key | Exclusion key | Exclusion key |
Exclusion key | Exclusion clear key | xattr_error (failed) |
Exclusion clear key | Versioned | Exclusion clear key |
Exclusion clear key | Exclusion key | xattr_error (failed) |
Exclusion clear key | Exclusion clear key | Exclusion clear key |
Rename Operation
The table below illustrates the status and the key effect of rename operations for different combinations of versioned, exclusion key, and exclusion clear key.
Key Applied to File in Backup | Key Applied to existing file in GuardPoint | Key Effect of Restore Operation on Existing file |
---|---|---|
Versioned | Versioned | Versioned |
Versioned | Exclusion key | Exclusion key |
Versioned | Exclusion clear key | xattr_error (failed) |
Exclusion key | Versioned | Exclusion key |
Exclusion key | Exclusion key | Exclusion key |
Exclusion key | Exclusion clear key | Exclusion key |
Exclusion clear key | Versioned | Exclusion clear key |
Exclusion clear key | Exclusion key | Exclusion clear key |
Exclusion clear key | Exclusion clear key | Exclusion clear key |