[bug] fscrypt incorrectly assumes its configuration and metadata paths are ordinary files and directories

[TheSast]

I first noticed this with /etc/fscrypt.conf. It looks like fscrypt tries to update this file by creating a temporary file, removing the old file, and then replacing it with the new one, but this causes issues when /etc/fscrypt.conf is a bind mount (since removing the path fails¹), or a symlink (since replacing the symlink means the new file is no longer written to the intended location).

A similar issue exists with /.fscrypt. Some systems use automated mechanisms to recreate paths that are stored elsewhere² (for example, through the aforementioned bind mounts or similar approaches). These mechanisms may create the directory before fscrypt has initialized it, resulting in an empty /.fscrypt. fscrypt then fails to write to it's directory³ even though no fscrypt metadata is present.

If I understood correctly, this issue seems related to #327

¹ - with output [ERROR] fscrypt setup: remove /etc/fscrypt.conf: device or resource busy.
² - such as NixOS with impermanence/preservation setups.
³ - with output similar to [ERROR] fscrypt setup: rename /.tmp2978932384/.fscrypt /.fscrypt: file exists.

[ebiggers]

I first noticed this with /etc/fscrypt.conf. It looks like fscrypt tries to update this file by creating a temporary file, removing the old file, and then replacing it with the new one, but this causes issues when /etc/fscrypt.conf is a bind mount (since removing the path fails²), or a symlink (since replacing the symlink means the new file is no longer written to the intended location).

This only occurs if you ask it to re-create the config file, though. What behavior did you expect in that case? I guess overwrite the file directly, even though that is non-atomic?

A similar issue exists with /.fscrypt. Some systems use automated mechanisms to recreate paths that are stored elsewhere¹ (for example, through the aforementioned bind mounts or similar approaches). These mechanisms may create the directory before fscrypt has initialized it, resulting in an empty /.fscrypt. fscrypt then fails to write to it's directory³ even though no fscrypt metadata is present.

If .fscrypt is created by something other than the fscrypt program itself then it should create the two subdirectories as well, and assign all three directories the correct mode. I guess you expected it to instead delete what was there already when it found something wrong?

This issue with fscrypt leads me to think that, if feasible, fscrypt's would benefit from having configurable metadata directory locations instead of assuming them.

This feels like an unrelated feature request?

[TheSast]

What behavior did you expect in that case?

The behavior I would expect is that, if the target is identified as a bind mount or symlink, fscrypt updates the existing file in place rather than replacing the path itself. This would allow those setups to function, even if it means giving up atomic replacement in said cases.

If .fscrypt is created by something other than the fscrypt program itself then it should create the two subdirectories as well, and assign all three directories the correct mode.

For /.fscrypt, I don't think mechanisms creating the directory should be expected to know about fscrypt's internal layout. For example if /.fscrypt cannot always live directly on the root filesystem and its contents need to be redirected elsewhere, the redirecting mechanism needs to create that path before fscrypt initializes it, as bind mounts require the target path to exist beforehand, and symlinks also occupy that path. In these cases, fscrypt will encounter an existing but uninitialized /.fscrypt directory.

I guess you expected it to instead delete what was there already when it found something wrong?

I would expect that behavior when the directory exists but is empty, since there is no existing fscrypt metadata to preserve in that case.

This feels like an unrelated feature request?

I'll move the configurable metadata location proposal into a separate issue.