About the Exclusion Attribute for Files Matching an Exclusion Key Rule

Files matching an exclusion key rule have the status rekey_excluded in the LDT attribute. For more information about LDT attributes, see 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 the voradmin output. For example:

  voradmin ldt attr get /oxf-fs1/gp1/foo.txt
  LDT attributes: rekeyed_size=0, rekey_status=rekey_excluded
  

• On Windows, an excluded file will include the attribute Rekey Status Excluded in the voradmin output. For example:

  C:\> voradmin ldt attr get c:\gp1\foo.txt
  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.

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.

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.

Rename Operation

The table below illustrates the status and the key effect of rename operations on files for different combinations of versioned, exclusion key, and exclusion clear key.