fix: secureblue-unbound-key systemd unit#1967
Merged
EsseLowNitro merged 6 commits intosecureblue:livefrom Feb 23, 2026
Merged
Conversation
The symlinks under /usr/etc/unbound/ and /etc/unbound/ are identical, but due to the symlink being relative, only the version in /etc/unbound/ points to valid path.
ConditionPathExists only checks for files and ignores symlinks, but /var/lib/unbound/root.key can also exist as a symlink. This commit reworks the check to use ExecCondition instead and use test -e, which also works on symlinks.
EsseLowNitro
previously approved these changes
Feb 23, 2026
HastD
requested changes
Feb 23, 2026
Collaborator
HastD
left a comment
HastD
left a comment
There was a problem hiding this comment.
The
ConditionPathExistsprecondition only works on files and ignores symlinks.
That's not actually true, as documented here:
Except for
ConditionPathIsSymbolicLink=, all path checks follow symlinks.
So are you sure that's actually the issue? Another possibility is that the system service manager might be failing to follow the symlink due to SELinux. (I actually just ran into this with Homebrew; see secureblue/homebrew#16.)
In any case, I recommend keeping the negated ConditionPathExists check as it will avoid having to run the service at all if it detects the path does exist, and the failure mode (if it incorrectly fails to detect the path for whatever reason) would be to run the service and be stopped by the ExecCondition you added, which is fine.
This does indeed work on symlinks; The actual reason for it not working in this case was SELinux. Add this back as a more efficient case on files, and keep the ExecCondition as a failsafe for symlinks.
HastD
approved these changes
Feb 23, 2026
Collaborator
Author
Oh, interesting! When I did my testing and initially looked into this issue, I noticed that on a fresh securecore install the service ran, even though the file existed in form of a symlink. After I tested the same with a file in its place and saw it correctly skipped, I (in hindsight falsely) drew my conclusion that this option just doesn't work on symlinks. But you were right indeed. After testing with As per your suggestion I added the |
EsseLowNitro
approved these changes
Feb 23, 2026
RoyalOughtness
approved these changes
Feb 23, 2026
PhysicsIsAwesome
pushed a commit
to PhysicsIsAwesome/secureblue
that referenced
this pull request
Mar 1, 2026
* fix: use correct symlink for secureblue-unbound-key unit The symlinks under /usr/etc/unbound/ and /etc/unbound/ are identical, but due to the symlink being relative, only the version in /etc/unbound/ points to valid path. * fix: rework secureblue-unbound-key execution condition ConditionPathExists only checks for files and ignores symlinks, but /var/lib/unbound/root.key can also exist as a symlink. This commit reworks the check to use ExecCondition instead and use test -e, which also works on symlinks. * fix: change RequiresMountsFor as well * chore: add ConditionPathExists back This does indeed work on symlinks; The actual reason for it not working in this case was SELinux. Add this back as a more efficient case on files, and keep the ExecCondition as a failsafe for symlinks.
PhysicsIsAwesome
pushed a commit
to PhysicsIsAwesome/secureblue
that referenced
this pull request
Mar 1, 2026
* fix: use correct symlink for secureblue-unbound-key unit The symlinks under /usr/etc/unbound/ and /etc/unbound/ are identical, but due to the symlink being relative, only the version in /etc/unbound/ points to valid path. * fix: rework secureblue-unbound-key execution condition ConditionPathExists only checks for files and ignores symlinks, but /var/lib/unbound/root.key can also exist as a symlink. This commit reworks the check to use ExecCondition instead and use test -e, which also works on symlinks. * fix: change RequiresMountsFor as well * chore: add ConditionPathExists back This does indeed work on symlinks; The actual reason for it not working in this case was SELinux. Add this back as a more efficient case on files, and keep the ExecCondition as a failsafe for symlinks.
RKNF404
pushed a commit
to RKNF404/secureblue
that referenced
this pull request
Mar 1, 2026
* fix: use correct symlink for secureblue-unbound-key unit The symlinks under /usr/etc/unbound/ and /etc/unbound/ are identical, but due to the symlink being relative, only the version in /etc/unbound/ points to valid path. * fix: rework secureblue-unbound-key execution condition ConditionPathExists only checks for files and ignores symlinks, but /var/lib/unbound/root.key can also exist as a symlink. This commit reworks the check to use ExecCondition instead and use test -e, which also works on symlinks. * fix: change RequiresMountsFor as well * chore: add ConditionPathExists back This does indeed work on symlinks; The actual reason for it not working in this case was SELinux. Add this back as a more efficient case on files, and keep the ExecCondition as a failsafe for symlinks.
PhysicsIsAwesome
pushed a commit
to PhysicsIsAwesome/secureblue
that referenced
this pull request
Mar 1, 2026
* fix: use correct symlink for secureblue-unbound-key unit The symlinks under /usr/etc/unbound/ and /etc/unbound/ are identical, but due to the symlink being relative, only the version in /etc/unbound/ points to valid path. * fix: rework secureblue-unbound-key execution condition ConditionPathExists only checks for files and ignores symlinks, but /var/lib/unbound/root.key can also exist as a symlink. This commit reworks the check to use ExecCondition instead and use test -e, which also works on symlinks. * fix: change RequiresMountsFor as well * chore: add ConditionPathExists back This does indeed work on symlinks; The actual reason for it not working in this case was SELinux. Add this back as a more efficient case on files, and keep the ExecCondition as a failsafe for symlinks.
PhysicsIsAwesome
pushed a commit
to PhysicsIsAwesome/secureblue
that referenced
this pull request
Mar 4, 2026
* fix: use correct symlink for secureblue-unbound-key unit The symlinks under /usr/etc/unbound/ and /etc/unbound/ are identical, but due to the symlink being relative, only the version in /etc/unbound/ points to valid path. * fix: rework secureblue-unbound-key execution condition ConditionPathExists only checks for files and ignores symlinks, but /var/lib/unbound/root.key can also exist as a symlink. This commit reworks the check to use ExecCondition instead and use test -e, which also works on symlinks. * fix: change RequiresMountsFor as well * chore: add ConditionPathExists back This does indeed work on symlinks; The actual reason for it not working in this case was SELinux. Add this back as a more efficient case on files, and keep the ExecCondition as a failsafe for symlinks.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
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.
The
secureblue-unbound-key.servicesystemd unit is currently broken in two ways:TheConditionPathExistsprecondition only works on files and ignores symlinks.Edit: ConditionPathExists does work on symlinks, but doesn't in this case due to SELinux.
/var/lib/unbound/root.keycan be a symlink (e.g. on a fresh securecore install) so this PR reworks this to useExecConditionwith a negatedtestcallinsteadadditionally, which does work on symlinks./usr/etc/unbound/dnssec-root.keyand/etc/unbound/dnssec-root.keyare identical symlinks, pointing to../../usr/share/dns-root-data/root.key. Due to the path being relative and only going back two folders, the symlink in/usr/etc/unbound/is broken and leads to the copy operation failing. This PR switches to using the working one in/etc/unbound/instead.