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. LDT supports a maximum of 16 concurrent renamed directories per GuardPoint in the scan or rekey phases. If an additional directory is renamed while there are already 16 directories being processed, the GuardPoint is marked for relaunch (See Rotating Encryption Keys While a Rekey is in Progress (Relaunch) for more information on the relaunch state). This will make rekey start again upon completion to pick up any additional renamed directories.

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

LDT can run a maximum of eight concurrent single 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.