Skip to content

Conversation

@kyrofa
Copy link
Contributor

@kyrofa kyrofa commented Jun 21, 2016

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.

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
Copy link
Contributor

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?

Copy link
Contributor Author

@kyrofa kyrofa Jun 21, 2016

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.

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)
Copy link
Contributor

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?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not used at all as far as I can see (so I'd prefer to remove it all together). @jdstrand or @zyga might have more information, as @zyga recommended I re-use the APP_NAME variable here.

Copy link
Contributor

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.

Copy link
Contributor Author

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?

Copy link
Contributor

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

@niemeyer
Copy link
Contributor

A few trivials, and one point worth talking about interactively.

Signed-off-by: Kyle Fazzari <kyle@canonical.com>
@kyrofa kyrofa force-pushed the feature/1586465/hook_apparmor branch from ba3fa99 to 98a20be Compare June 21, 2016 18:29
Signed-off-by: Kyle Fazzari <kyle@canonical.com>
@niemeyer
Copy link
Contributor

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)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm?

@mvo5
Copy link
Contributor

mvo5 commented Jun 22, 2016

Branch looks good! It seems fine to drop APP_NAME, we should just double check that it is not documented externally somewhere (looks like we don't have it in docs/*).

@kyrofa
Copy link
Contributor Author

kyrofa commented Jun 22, 2016

Branch looks good! It seems fine to drop APP_NAME, we should just double check that it is not documented externally somewhere (looks like we don't have it in docs/*).

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>
@zyga
Copy link
Contributor

zyga commented Jun 22, 2016

LGTM when tests pass

@kyrofa kyrofa merged commit 7112458 into canonical:master Jun 22, 2016
@kyrofa kyrofa deleted the feature/1586465/hook_apparmor branch June 22, 2016 13:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants