Renaming Directories on Linux

Prior to CTE-LDT v7.1.0, you could not rename a directory within a CTE-LDT GuardPoint, during the rekeying process. However, starting in CTE-LDT v7.1.1, users and applications can now rename directories within an CTE-LDT GuardPoint, during the rekeying process.

When a directory is renamed, CTE-LDT starts performing single file rekey jobs, on files in that renamed directory. A single file rekey job is a background process that rekeys a specific file, independent of the rekey process occurring on the entire GuardPoint. This process is similar to how files marked with a lazy rekey flag are rekeyed to the latest key version upon access to the marked file.

You can view rekey jobs in a GuardPoint using the command voradmin ldt list all. Rekey operations for files marked as lazy, as part of CipherTrust Intelligent Remediation, and for directory rename, are listed as separate single file rekey jobs. In the example below, the file /ldt/renamed/file.0 is undergoing rekey as a single file rekey job, as the result of changing the pathname to the file.

 voradmin ldt list all

MDS_1:  type=file, nguards=9, name=/ldt/::vorm:mds:: ::

    Guard Table: version 1 nentries 9

    Guard 0: type=GP, state=REKEYING DIRTY, flags=GP LOCKED, gp=/ldt

        File List: count 51

    Guard 1: type=FILE, state=REKEYING DIRTY, flags=FILE LOCKED, gp=/ldt/renamed_dir/file.0

        File List: count 1

CTE-LDT can run a maximum of eight concurrent file rekey jobs for directory renaming. This limit is shared across directory renames for all of the GuardPoints on a system.

Furthermore, while directory rename is in progress on a target GuardPoint, the GuardPoint will not transition into the rekeyed state, even if CTE-LDT has completed on the rest of the files in the GuardPoint. As soon as the single file rekey jobs associated with the GuardPoint complete, the GuardPoint transitions into a rekeyed state.