fix: always treat link destinations as files to ensure an error when the destination is a directory #187
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
If a secret is used in the initrd with stage1 systemd, it will be copied into the initrd on activation time, after agenix has run. If the system is then restarted, the directory /run/agenix will be created by the initrd because the file is included in the cpio archive. This will in turn cause agenix to silently create an incorrect link
/run/agenix/0 -> /run/agenix.d/0
instead of/run/agenix -> /run/agenix.d/0
when switching to stage2.Technically this is not a bug in agenix, since including a secret under
/run/agenix
can be considered invalid use. Yet I believe it would be good if agenix errors in such cases instead of creating a wrong link, to make users aware of the issue. Therefore I propose to replaceln -sfn
withln -sfT
which will unconditionally treat the target as a file, and as such error if the target is a directory.Another approach is to force remove any existing directories, which might also be a desirable alternative option. This would then allow using agenix secrets in the systemd stage1 initrd without taking any special care. But as unconditionally removing might be a undesirable default behavior, this could require a new option. Do you have an opinion on this matter?