i/apparmor: add missing expansion for s-u-n template #13853
Merged
Conversation
This file contains 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
This fixes access to /etc/apparmor.d/tunables when running from snapd snap. When snapd snap re-executes, and uses apparmor_parser from snapd snap (those are separate conditions), then it re-directs the parser away from host /etc/apparmor.d and we have special code to load tunables from the host anyway. Those tunables are themselves conditional on the conditional include syntax that may or may not be supported by apparmor (otherwise the would be explicitly spelled out in the template, and not dynamically expanded with custom logic). The problem was introduced along with patch b98e4af (i/apparmor: support for home.d tunables from /etc/ (snapcore#13118)), as the case for snap-update-ns was missed, and the default expansion is an empty string. Regression-testing this requires that we re-package snapd snap, so the test will come in with a separate patch as it requires somewhat more effort to behave correctly. This issue was identified by Maciej Borzecki. Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>
bboozzoo
approved these changes
Apr 18, 2024
| } | ||
| return "" | ||
| default: | ||
| // TODO: Warn that an invalid pattern is being used. |
ernestl
pushed a commit
to ernestl/snapd
that referenced
this pull request
Apr 18, 2024
This fixes access to /etc/apparmor.d/tunables when running from snapd snap. When snapd snap re-executes, and uses apparmor_parser from snapd snap (those are separate conditions), then it re-directs the parser away from host /etc/apparmor.d and we have special code to load tunables from the host anyway. Those tunables are themselves conditional on the conditional include syntax that may or may not be supported by apparmor (otherwise the would be explicitly spelled out in the template, and not dynamically expanded with custom logic). The problem was introduced along with patch b98e4af (i/apparmor: support for home.d tunables from /etc/ (snapcore#13118)), as the case for snap-update-ns was missed, and the default expansion is an empty string. Regression-testing this requires that we re-package snapd snap, so the test will come in with a separate patch as it requires somewhat more effort to behave correctly. This issue was identified by Maciej Borzecki. Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>
ernestl
pushed a commit
that referenced
this pull request
Apr 24, 2024
This fixes access to /etc/apparmor.d/tunables when running from snapd snap. When snapd snap re-executes, and uses apparmor_parser from snapd snap (those are separate conditions), then it re-directs the parser away from host /etc/apparmor.d and we have special code to load tunables from the host anyway. Those tunables are themselves conditional on the conditional include syntax that may or may not be supported by apparmor (otherwise the would be explicitly spelled out in the template, and not dynamically expanded with custom logic). The problem was introduced along with patch b98e4af (i/apparmor: support for home.d tunables from /etc/ (#13118)), as the case for snap-update-ns was missed, and the default expansion is an empty string. Regression-testing this requires that we re-package snapd snap, so the test will come in with a separate patch as it requires somewhat more effort to behave correctly. This issue was identified by Maciej Borzecki. Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This fixes access to /etc/apparmor.d/tunables when running from snapd snap. When snapd snap re-executes, and uses apparmor_parser from snapd snap (those are separate conditions), then it re-directs the parser away from host /etc/apparmor.d and we have special code to load tunables from the host anyway. Those tunables are themselves conditional on the conditional include syntax that may or may not be supported by apparmor (otherwise the would be explicitly spelled out in the template, and not dynamically expanded with custom logic).
The problem was introduced along with patch
b98e4af (i/apparmor: support for home.d tunables from /etc/ (#13118)), as the case for snap-update-ns was missed, and the default expansion is an empty string.
Regression-testing this requires that we re-package snapd snap, so the test will come in with a separate patch as it requires somewhat more effort to behave correctly.
This issue was identified by Maciej Borzecki.