-
Notifications
You must be signed in to change notification settings - Fork 652
interfaces: add apparmor support for hooks. #1373
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
interfaces: add apparmor support for hooks. #1373
Conversation
Also add Spread tests for app and hook AppArmor profiles. Updates: #1586465 Signed-off-by: Kyle Fazzari <kyle@canonical.com>
| @@ -0,0 +1,2 @@ | |||
| name: basic-hooks | |||
| version: 1.0 | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm
Don't you have to declare the hooks here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Only if they require plugs. Otherwise they're implicit just by being included in the snap.
interfaces/apparmor/template_vars.go
Outdated
| fmt.Fprintf(&buf, "@{APP_NAME}=\"%s\"\n", appInfo.Name) | ||
| fmt.Fprintf(&buf, "@{SNAP_NAME}=\"%s\"\n", appInfo.Snap.Name()) | ||
| fmt.Fprintf(&buf, "@{SNAP_REVISION}=\"%s\"\n", appInfo.Snap.Revision) | ||
| fmt.Fprintf(&buf, "@{APP_NAME}=\"%s\"\n", appName) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A bit worried here as we're mixing app name and hook name on the same namespace with the same variable name. How is this variable being used today, and what is the potential for security issues?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reusing sounds quite dangerous, even more if we have no use case to understand why it'd be okay to reuse it without it being a security issue. If we're not using it today, let's please drop it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From @jdstrand:
I can say we used APP_NAME extensively on touch and may with personal. I'd prefer not to drop it until we know we don't need it, and I can't say we won't for personal.
So maybe it comes down to whether we want to re-use APP_NAME, or introduce HOOK_NAME?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We agreed to drop this var for the time being.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
|
A few trivials, and one point worth talking about interactively. |
Signed-off-by: Kyle Fazzari <kyle@canonical.com>
ba3fa99 to
98a20be
Compare
Signed-off-by: Kyle Fazzari <kyle@canonical.com>
|
LGTM |
| func templateVariables(appInfo *snap.AppInfo) []byte { | ||
| func templateVariables(info *snap.Info) []byte { | ||
| var buf bytes.Buffer | ||
| fmt.Fprintf(&buf, "@{APP_NAME}=\"%s\"\n", appInfo.Name) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm?
|
Branch looks good! It seems fine to drop |
Thanks for the review @mvo5! Agreed about the documentation: It's not mentioned in snapd anywhere and I'm not seeing anything on google. That combined with the fact that it wasn't being used for anything makes me feel fairly comfortable removing it. |
Signed-off-by: Kyle Fazzari <kyle@canonical.com>
|
LGTM when tests pass |
More progress on LP: #1586465. Also port AppArmor integration tests to Spread and include tests for hooks. Note that this isn't a complete port (it requires a reboot), so the old integration tests are left alone.