Predictable handling of encrypted EXT4 directories on Linux

For now the error when accessing an encrypted EXT4 directory by the backup client can be ignored by a setting in dsm.sys (see support case). But this leads to the effect, that an encrypted directory will be considered in a backup if the encryption key is currently available for the account running the backup client and the backup will be made. If during the next run the encryption key is no longer available, the just saved data will be erased again in the backup. Then it might be again in the backup and erased again. This is not really the behavior for a clean backup, as one can’t know the actual state of the data in the backup.

My suggestion is to introduce a new keyword in dsm.sys: ENCRYPTEDEXT4DIR with the possible values NEVER, IFKEY, KEEP, ALWAYS, FAIL

NEVER

With the high level call “/usr/sbin/e4crypt get_policy /mnt/an_encrypted_dir” one can check whether a directory is encrypted (independent whether the key is actually available or not), hence this call has to be made for every directory in the backup. If it turns out that a directory is encrypted, this should be skipped and any backup found for this directory will be erased. NEVER essentially means that there won’t be any data for this directory in the backup.

IFKEY

In case that for a found directory (checked with the call “/usr/sbin/e4crypt get_policy /mnt/an_encrypted_dir” like above) the key is available (hence no ENOKEY (126) error for the backup client) the backup will take place. If the key is not available, the handling of the directory will be skipped. Most important it won’t erase any data which were saved during a former run when the encryption key for this directory was available. It will only erase files (i.e. expire in the backup), when the key is available and the content of the directory changed by intention of the user.

KEEP

The state of a directory whether it’s encrypted or not can be done by the end user without any special rights, but during the change of the policy the directory has to be empty. The behavior of KEEP should be, that any backup which was made while the directory was not encrypted will be kept but any new backup skipped. It’s similar to the option NEVER but it won’t erase any old found data.

ALWAYS

This is the actual behavior, but I don’t see a real application for this setting.

FAIL

This will generate a special error message telling the admin to provide a key to perform the backup. The complete backup client will exit with a special error code which can checked by any invoking software. Maybe there are installations, where the backup client should only run when all encryption keys are in place.