Checking for Hard-Link Files Inside the GuardPoint with Data Transformation

Guarding and transforming linked files is potentially dangerous. Links require special consideration. Depending on how policies and keys are applied to both the link file/directory and the source file/directory, there is the potential for policy conflicts and key mismatches. A key mismatch will corrupt data files when they are saved. See also Dataxform and Linked Files. for more information.

With regard to links:

• There is only one instance of a file; where, with links, it can have multiple names. The instance is transformed when the first name for it is encountered. Subsequent names are recognized as aliases of the already transformed instance and are ignored.

• Never make a links to sources outside of the GuardPoint. If a file in a GuardPoint is linked to a file in another GuardPoint, and encryption is applied, cross-changes to the same file from different GuardPoints will use different keys and corrupt files.

• If a file in a GuardPoint is a link to a file that is not in any GuardPoint, then only standard operating system access controls are applied to the file outside the GuardPoint. That means that root, and possibly others, can access and modify the file instance without an encryption key and without restriction. Only the file instance in the GuardPoint should be accessed, otherwise the key will not be used to decrypt/encrypt the instance. If the instance is changed and saved outside of the GuardPoint, it will be corrupted.

• Security rules for link files inside the GuardPoint must be intelligently written to anticipate how files are accessed and how keys are applied. For example, you can create a file named a.foo and create a link to it named a.bar. If you write a security rule that applies one key to *.foo and another key to *.bar, the key applied depends upon how the file is accessed. Again, this is an opportunity for cross-changes and file corruption.

The --check_links example below detected links. It found three hard links to files outside the GuardPoint and two to files inside the GuardPoint. The dataxform output includes the full path names of the hard-link files detected in the GuardPoint. Note the lines that read:

Found 1 references to hard link but expected 2

Because dataxform “expected” more links than it found, a likely culprit is that the file inside the GuardPoint is linked to a file outside the GuardPoint. We strongly recommend that links do not go outside the GuardPoint because policy and key application can become unpredictable and corrupt files.

Also, note the lines that read:

Found 2 references to hard link

These lines indicate that the link file and the source file both reside inside the GuardPoint.

# dataxform --check_links --gp /opt/apps/dx2
Status information for directories in guard point
Directory /opt/apps/dx2/ab_dir/ contains 2002 files (57 KB)
Directory /opt/apps/dx2/ac_dir/ contains 2000 files (57 KB)
Directory /opt/apps/dx2/ad_dir/ contains 2000 files (57 KB)
Directory /opt/apps/dx2/aa_dir/ contains 2000 files (57 KB)
Directory /opt/apps/dx2/ contains 2003 files (43 KB)
Scan found 10005 files (273 KB) in 5 directories for guard point /opt/apps/dx2
Scanning for hard links in directory /opt/apps/dx2
Found 1 references to hard link but expected 2
Hardlink reference 1 /opt/apps/dx2/hardlinkfile01
Found 1 references to hard link but expected 2
Hardlink reference 1 /opt/apps/dx2/hardlinkfile02
Found 1 references to hard link but expected 2
Hardlink reference 1 /opt/apps/dx2/hardlinkfile03
Found 2 references to hard link
Hardlink reference 1 /opt/apps/dx2/hardlinkedfileLocal02
Hardlink reference 2 /opt/apps/dx2/ab_dir/linkedfile02
Found 2 references to hard link
Hardlink reference 1 /opt/apps/dx2/hardlinkedfileLocal01
Hardlink reference 2 /opt/apps/dx2/ab_dir/linkedfile01